From: Andrea Arcangeli <andrea@suse.de>
To: Paul Mackerras <paulus@samba.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: please revert bogus patch to vmscan.c
Date: Wed, 31 Oct 2001 02:57:59 +0100 [thread overview]
Message-ID: <20011031025759.H1340@athlon.random> (raw)
In-Reply-To: <20011030175417.K1340@athlon.random> <XFMail.20011030182326.pochini@shiny.it> <20011030183058.O1340@athlon.random> <15327.8495.767553.389519@cargo.ozlabs.ibm.com>
In-Reply-To: <15327.8495.767553.389519@cargo.ozlabs.ibm.com>; from paulus@samba.org on Wed, Oct 31, 2001 at 08:52:47AM +1100
Hello Paul,
On Wed, Oct 31, 2001 at 08:52:47AM +1100, Paul Mackerras wrote:
> pte value to the corresponding HPTE. The performance impact of
> maintaining the accessed and dirty bits in software is negligible
The accessed bit is worthless to be maintained in software. Infact if it
is true that ppc doesn't have an hardware maintained accessed bit (like
alpha) this means ppc _doesn't_ want the tlb flush, just like alpha,
unlike said previously today in other emails. the whole
ptep_test_and_clear_young section + tlb flush should be #ifndeffed out
for those archs. The waste is to care about this non existent accessed
bit in first place for those archs. Those archs enterely depend on the
minor faults to activate the cache and so we can only unmap
unconditionally the inactive cache on those archs. Infact on those archs
we should probably deactivate all the cache, not only the inactive one,
so that it has a better change to keep the working set in active cache.
with regard to the dirty bit while fixing x86 smp races, Ben did
benchmarks that showed the performance hit isn't negligible if
maintained in software, you know it generates the doube of page faults
with the "right" benchmark, but maybe this is the only sane approch for
ppc.
Andrea
next prev parent reply other threads:[~2001-10-31 1:57 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 [this message]
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
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=20011031025759.H1340@athlon.random \
--to=andrea@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox