Re: ~500 megs cached yet 2.6.5 goes into swap hell

[Nick Piggin <nickpiggin@yahoo.com.au>]

Marc Singer wrote:
> On Thu, Apr 29, 2004 at 01:48:02PM +1000, Nick Piggin wrote:
> 
>>Marc Singer wrote:
>>
>>>On Thu, Apr 29, 2004 at 10:21:24AM +1000, Nick Piggin wrote:
>>>
>>>
>>>>Anyway, I have a small set of VM patches which attempt to improve
>>>>this sort of behaviour if anyone is brave enough to try them.
>>>>Against -mm kernels only I'm afraid (the objrmap work causes some
>>>>porting difficulty).
>>>
>>>
>>>Is this the same patch you wanted me to try?  
>>>
>>> Remember, the embedded system where NFS IO was pushing my
>>> application out of memory.  Setting swappiness to zero was a
>>> temporary fix.
>>>
>>>
>>
>>Yes this is the same patch I wanted you to try. Yes I
>>remember your problem!
>>
>>Didn't anyone come up with a patch for you to test the
>>stale PTE theory? If so, what where the results?
> 
> 
> Russell King is working on a lot of things for the MMU code in ARM.
> I'm waiting to see where he ends up.  I believe he's planning on
> removing the lazy PTE release logic.
> 
> I hacked at it for some time.  And I'm convinced that I correctly
> forced the TLBs to be flushed.  Still, I was never able to get the
> system to behave.
> 
> Now, I just read a comment you or WLI made about the page cache
> use-once logic.  I wonder if that's the real culprit?  As I wrote to
> Andrew Morton, the kernel seems to be assigning an awful lot of value
> to page cache pages that are used once (or twice?).  I know that it
> would be expensive to perform an HTG aging algorithm where the head of
> the LRU list is really LRU.  Does your patch pursue this line of
> thought?
> 

Yes it includes something which should help that. Along with
the "split active lists" that I mentioned might help your
problem when WLI first came up with the change to the
swappiness calculation for your problem.

It would be great if you had time to give my patch a run.
It hasn't been widely stress tested yet though, so no
production systems, of course!