From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Linux Kernel list <linux-kernel@vger.kernel.org>,
Rik van Riel <riel@surriel.com>, Andrew Morton <akpm@osdl.org>,
Andrea Arcangeli <andrea@suse.de>
Subject: Re: Page aging broken in 2.6
Date: Sat, 27 Dec 2003 11:44:59 +1100 [thread overview]
Message-ID: <1072485899.15456.96.camel@gaston> (raw)
In-Reply-To: <Pine.LNX.4.58.0312261626260.14874@home.osdl.org>
On Sat, 2003-12-27 at 11:35, Linus Torvalds wrote:
> On Sat, 27 Dec 2003, Benjamin Herrenschmidt wrote:
> >
> > Or do what I propose here, that is have ptep_test_and_clear_* be
> > responsible for the flush on archs where it is necessary, but then
> > it would be nice to have more than the ptep as an argument...
>
> 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 know whather that ever ends up being performance-critical, and I
> don't see what else could be passed into it. We literally don't _have_
> anythign else than the pte.
Ok, figured that out.
> But the ppc architecture could easily decide to walk the hash tables and
> invalidate in ptep_test_and_clear_young(). And if it ends up being a
> performance issue, it _appears_ that all users of "page_referenced()"
> (which is the only thing that does this) are actually using the return
> value as just a boolean. And it's entirely possible that we should break
> out of "page_referenced()" on the _first_ hit of "yes, this has been
> referenced".
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.
> That would make it much less CPU-intensive to make
> "ptep_test_and_clear_young()" slightly heavier to execute. It would also
> cause "page_referenced()" to not clear _all_ mapped reference bits at the
> same time - which might unfairly cause multi-used pages to stay in memory.
> On the other hand, that might be the _right_ behaviour.
>
> Rik? Andrea?
>
> Worth testing, perhaps.
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.
Ben.
next prev parent reply other threads:[~2003-12-27 0:45 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-26 7:28 Page aging broken in 2.6 Benjamin Herrenschmidt
2003-12-26 7:40 ` Andrew Morton
2003-12-26 9:21 ` Arjan van de Ven
2003-12-26 9:58 ` Benjamin Herrenschmidt
2003-12-26 19:44 ` Davide Libenzi
2003-12-26 9:33 ` Russell King
2003-12-26 10:07 ` Benjamin Herrenschmidt
2003-12-26 17:59 ` Linus Torvalds
2003-12-26 23:55 ` Benjamin Herrenschmidt
2003-12-27 0:35 ` Linus Torvalds
2003-12-27 0:44 ` Benjamin Herrenschmidt [this message]
2003-12-27 0:53 ` Linus Torvalds
2003-12-27 0:59 ` Linus Torvalds
2003-12-27 1:03 ` Benjamin Herrenschmidt
2003-12-27 2:37 ` Andrea Arcangeli
2003-12-27 5:02 ` Benjamin Herrenschmidt
2003-12-27 10:16 ` William Lee Irwin III
2003-12-27 2:47 ` Rik van Riel
2003-12-27 3:00 ` Andrew Morton
2003-12-27 3:31 ` Rik van Riel
2003-12-27 3:54 ` Linus Torvalds
2003-12-27 16:34 ` Martin J. Bligh
2003-12-27 23:07 ` Roger Luethi
2003-12-27 23:55 ` William Lee Irwin III
2003-12-28 11:23 ` Roger Luethi
2003-12-28 16:35 ` William Lee Irwin III
2003-12-28 17:15 ` Roger Luethi
2003-12-28 0:04 ` Andrew Morton
2003-12-28 11:58 ` Roger Luethi
2003-12-27 1:41 ` Andrea Arcangeli
-- strict thread matches above, loose matches on Subject: below --
2003-12-26 10:45 Manfred Spraul
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1072485899.15456.96.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=akpm@osdl.org \
--cc=andrea@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@surriel.com \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.