Re: Page aging broken in 2.6

From: Linus Torvalds
Date: Fri Dec 26 2003 - 19:55:11 EST




On Sat, 27 Dec 2003, Benjamin Herrenschmidt wrote:
> >
> > The dirty handling already does the TLB flush (in that case it's a
> > correctness issue, not a hint). So it's only ptep_test_and_clear_young()
> > that matters.
>
> Yes, but it would be possible to optimize it some way on our
> beloved hash tables ;) (By marking the entry read-only in the
> hash instead of evicting it). Maybe not worth the pain though...

I don't think you should evict it, since
- you know the value it should have
- if you do the hash lookup anyway, you might as well just update the
entry.

And it's not "read-only" - it's the "A" bit, not the "W" bit you should be
clearing in "ptep_test_and_clear_young()".

> Except that we may expect all "referencing" PTEs to have the accessed
> bit cleared, no ? Or if we have lots of users we'll end up getting lots
> of positive results while after the page was actually referenced... I
> don't know if this would be a real problem though.

I'll let Rik and Andrea argue that part - it's entirely possible that
getting lots of positive results is a _good_ thing, if the same page is
mapped multiple times. That would just make us less eager to unmap it,
which sounds like potentially the right thign to do (it's also how the old
non-rmap code worked, and I know Rik thought it was "unfair", but
whatever).

> Ok, right now, Anton is testing a patch from paulus where we do our
> own flush batching and do the flush inside ptep_test_and_clear_* That
> will at least fix the problem for us now.

Yeah, and it's unlikely to be a performance problem anyway. That function
should be called only when we're low on memory..

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/