On Sun, 8 Jun 2008 20:56:29 -0400 Rik van Riel <riel@redhat.com> wrote:
Well. Intrusiveness doesn't matter much. But no, you're dead wrong -
this stuff is far more risky than timer changes. Because things like
the timer changes are trivial to detect errors in - it either works or
it doesn't.
Whereas reclaim problems can take *years* to identify and are often
very hard for the programmers to understand, reproduce and diagnose.
Earlier discussion about removing these pages from ALL LRUs reached a
quite detailed stage, but nobody seemed to finish any code.
We shouldn't rewrite core VM to cater for incorrectly configured
systems.
I see handwavy non-bug-reports loosely associated with a vast pile of
code and vague expressions of hope that one will fix the other.
Where's the meat in this, Rik? This is engineering.
Do you or do you not have a test case which demonstrates this problem?
It doesn't sound terribly hard. Where are the before-and-after test
results?
I'd love to see hard evidence that they have been. And that doesn't
mean getting palmed off on wikis and random blog pages.
Also, it is incumbent upon us to consider the other design proposals,
such as removing anon pages from the LRUs, removing mlocked pages from
the LRUs.
That actually isn't a fundamental problem.
It _becomes_ a problem because we try to treat the two types of pages
differently.
Stupid question: did anyone try setting swappiness=100? What happened?
Well for starters that system was grossly misconfigured. It is
incumbent upon you, in your design document (that thing we call a
changelog) to justify why the VM design needs to be altered to cater
for such misconfigured systems. It just drives me up the wall having
to engage in a 20-email discussion to be able to squeeze these little
revelations out. Only to have them lost again later.
Secondly, I expect that removal of mlocked pages from the LRU (as was
discussed a year or two ago and perhaps implemented by Andrea) along
with swappiness=100 might be get us towards a fix. Don't know.
Unless I missed it, none of your patch descriptions even attempt to
describe these fundamental issues. It's all buried in 20-deep email
threads.
I see no fundamental reason why we need to put mlocked or SHM_LOCKED
pages onto a VM LRU at all.
One cause of problms is that we attempt to prioritise anon pages over
file-backed pagecache. And we prioritise mmapped pages, which your patches
don't address, do they? Stopping doing that would, I expect, prevent a
range of these problems. It would introduce others, probably.
-mm isn't a very useful testing place any more, I'm afraid. The
patches would be better off in linux-next, but then they would screw up
all the other pending MM patches, and it's probably a bit early for
getting them into linux-next.
Once I get sections of -mm feeding into linux-next, things will be better.
That helps.
--
