On Wed, 14 Jun 2000, Rik van Riel wrote:
>Ermmm, I mean that trying to _balance_ the zone is the right
>thing to do. Consuming infinite CPU time when we can't succeed
>is a clear bug we want to fix.
Actually consuming CPU is the right thing to do. The other option is to
understand the zone is all mlocked and that it doesn't worth to waste CPU
there. If you're going to just break the kswapd loop after some time then
you're inserting a bug and you're making the VM even less robust.
What I was trying to explain is not how the VM reacts to too big mlocked
regions, but just how much the current design doesn't see the whole
picture about the property of the memory and how it ends doing something
very stupid in my testcase (the one first mlocked and then cache). The
fact it does something stupid is _only_ the sympthom. Whatever you do with
mlocked accounting can only fix the sympthom.
As soon as time permits I'll try to do another example of the current lack
of knowledge of the VM with respect to the property of the VM (and how
this ends doing yet other silly things). These emails are very expensive
in terms of time and I need to do some more real coding now ;).
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:34 EST