From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: <linux-kernel@vger.kernel.org>,
"David S. Miller" <davem@redhat.com>,
Andrea Arcangeli <andrea@suse.de>,
Benjamin LaHaise <bcrl@redhat.com>, <paulus@samba.org>
Subject: Re: please revert bogus patch to vmscan.c
Date: Tue, 30 Oct 2001 18:23:52 +0100 [thread overview]
Message-ID: <20011030172352.16727@smtp.adsl.oleane.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0110300835140.8603-100000@penguin.transmeta.com>
In-Reply-To: <Pine.LNX.4.33.0110300835140.8603-100000@penguin.transmeta.com>
>Now, it's not true on _all_ PPC's.
>
>The sane PPC setups actually have a regular soft-filled TLB, and last I
>saw that actually performed _better_ than the stupid architected hash-
>chains. And for the broken OS's (ie AIX) that wants the hash-chains, you
>can always make the soft-fill TLB do the stupid thing..
>
>(Yeah, yeah, I'm sure you can find code where the hash-chains are faster,
>especially big Fortran programs that have basically no tear-down and
>build-up overhead. Which was why those things were designed that way, of
>course. But it _looks_ like at least parts of IBM may finally be wising up
>to the fact that hashed TLB's are a stupid idea).
Well, I lack experience to state which scheme is better, but there is
definitely overhead intruduced by our hash management in linux on ppc,
since we have to evicts pages from the hash as soon as we test&clear
PAGE_ACCESSED or PAGE_DIRTY.
That means we keep flushing pages out of the hash table, which seems
to be defeat the purpose of that big hash table supposed to hold the
PTEs for everybody out there more/less permanently.
However, I was thinking about a possible solution, please tell me
if I'm completely off here or if it makes sense.
Since we can't (AFAIK) have linux use larger PTEs (in which case we
could store a pointer to the hash PTE in the linux PTE), We could
instead layout an array of pointer (one for each page) that would
hold these.
That way, we have a fast way to grab the real accessed and dirty
bits, which means we no longer need to flush hash pages when getting
those bits and have a more realistic PAGE_ACCESSED (currently, any page
in the hash has PAGE_ACCESSED).
Comments ?
Ben.
next prev parent reply other threads:[~2001-10-30 17:24 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-29 23:08 please revert bogus patch to vmscan.c Benjamin LaHaise
2001-10-29 23:14 ` David S. Miller
2001-10-29 23:15 ` Benjamin LaHaise
2001-10-29 23:25 ` Linus Torvalds
2001-10-29 23:33 ` Benjamin LaHaise
2001-10-29 23:36 ` David S. Miller
2001-10-29 23:39 ` Benjamin LaHaise
2001-10-29 23:41 ` Linus Torvalds
2001-10-29 23:48 ` Benjamin LaHaise
2001-10-29 23:50 ` David S. Miller
2001-10-29 23:51 ` Benjamin LaHaise
2001-10-29 23:55 ` David S. Miller
2001-10-29 23:57 ` Benjamin LaHaise
2001-10-30 0:01 ` David S. Miller
2001-10-30 0:05 ` Benjamin LaHaise
2001-10-29 23:58 ` Linus Torvalds
2001-10-30 1:31 ` Rik van Riel
2001-10-30 1:34 ` David S. Miller
2001-10-30 1:42 ` Linus Torvalds
2001-10-30 1:46 ` David S. Miller
2001-10-30 2:25 ` Benjamin LaHaise
2001-10-30 15:20 ` Andrea Arcangeli
2001-10-30 15:34 ` Rik van Riel
2001-10-30 15:51 ` Andrea Arcangeli
2001-10-30 16:34 ` Benjamin LaHaise
2001-10-30 17:00 ` Andrea Arcangeli
2001-10-30 17:07 ` Rik van Riel
2001-10-30 16:13 ` Giuliano Pochini
2001-10-30 16:54 ` Andrea Arcangeli
2001-10-30 17:23 ` Giuliano Pochini
2001-10-30 17:30 ` Andrea Arcangeli
2001-10-31 0:38 ` Paul Mackerras
[not found] ` <15327.8495.767553.389519@cargo.ozlabs.ibm.com>
2001-10-31 1:57 ` Andrea Arcangeli
2001-10-30 16:38 ` Linus Torvalds
2001-10-30 16:47 ` Benjamin LaHaise
2001-10-30 16:57 ` Victor Yodaiken
2001-10-30 17:16 ` Troy Benjegerdes
2001-10-30 17:17 ` Linus Torvalds
2001-10-30 17:51 ` Victor Yodaiken
2001-10-30 18:01 ` Cort Dougan
2001-10-30 21:39 ` Paul Mackerras
2001-10-30 22:36 ` Victor Yodaiken
2001-10-30 17:23 ` Benjamin Herrenschmidt [this message]
2001-10-30 17:36 ` Benjamin Herrenschmidt
2001-10-30 17:41 ` Linus Torvalds
2001-10-30 1:49 ` Benjamin LaHaise
2001-10-30 9:03 ` Alan Cox
2001-10-29 23:22 ` Linus Torvalds
2001-10-29 23:29 ` Benjamin LaHaise
2001-10-29 23:44 ` Linus Torvalds
2001-10-30 0:02 ` Hugh Dickins
2001-10-30 0:04 ` Linus Torvalds
2001-10-30 0:04 ` David S. Miller
2001-10-29 23:51 ` Paul Mackerras
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=20011030172352.16727@smtp.adsl.oleane.com \
--to=benh@kernel.crashing.org \
--cc=andrea@suse.de \
--cc=bcrl@redhat.com \
--cc=davem@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.org \
--cc=torvalds@transmeta.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox