[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-arm-kernel
Subject:    Re: On TLB flushing
From:       Marc Singer <elf () buici ! com>
Date:       2004-04-16 18:50:37
Message-ID: 20040416185037.GA19980 () flea
[Download RAW message or body]

On Fri, Apr 16, 2004 at 08:48:01PM +0200, Matthias Welwarsky wrote:
> On Friday 16 April 2004 17:18, Marc Singer wrote:
> > On Fri, Apr 16, 2004 at 04:10:52PM +0100, Russell King - ARM Linux wrote:
> > > Don't confuse the hardware PTE being cleared by act of clearing the
> > > young bit vs the page being unmapped.  These are two completely
> > > different operations.
> >
> > I don't think I am.  In the set_pte code, if the young bit is clear
> > then the hardware PTE is cleared.  At any point after this, a read to
> > that page should generate a fault, but that won't happen unless the
> > TLB is cleared.
> 
> Uh, interesting. In the 2.4 kernel, is the hardware PTE also being cleared 
> together with the YOUNG bit? Having a page fault on the next read (and the 
> YOUNG bit being set again) would be a great help in low memory situations, to 
> avoid executable pages from being discarded if they were in use recently.

I don't think that's a guaranteed result.  Since the TLB isn't being
cleared, there is no guarantee that the kernel will notice the page
access.  However, if the TLB is either flushed or the entry is
replaced *and* the page had not yet been reallocated, then the next
access will fault and restore the hardware PTE.  I don't know if the
kernel keeps track of this event for the sake of tuning page
replacement.

> > > With that change, any change to a PTE entry what so ever will result
> > > in a TLB flush happening, which isn't what's intended in every case.
> > > When a new PTE entry is created when none previously existed, we
> > > miss out the TLB flush.  When we clear the "young" bit, we miss out
> > > the TLB flush.  Adding in the TLB flush changes the system behaviour
> > > because you've now forced a page fault to occur next time that page
> > > is accessed.
> 
> Yes, but this would be very helpful for a more accurate emulation of the YOUNG 
> bit functionality. Maybe it slows down the system, but if you have to read 
> the page from a hard drive this is even slower.

What I have observed is that my little program is experiencing
frequent code page evictions.  There is only one code page and the
kernel seems to push it out much more often than seems desirable.  I
believe this is due to the heuristics in the refill_inactive_zone ()
function.  However, because my program is doing a network transfer I
don't think I could measure a performance change if I stopped the page
from being unmapped.  It's easy enough to do if you want to try.  Just
comment out the line in refill_inactive_zone() that sets
reclaim_mapped to 1.

Try it.  Let us know how it goes.

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:       http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php
[prev in list] [next in list] [prev in thread] [next in thread]