linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Martin J. Bligh" <mbligh@mbligh.org>
To: Christoph Lameter <clameter@engr.sgi.com>
Cc: torvalds@osdl.org, akpm@osdl.org, nickpiggin@yahoo.com.au,
	hugh@veritas.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: Hugh's alternate page fault scalability approach on 512p Altix
Date: Wed, 07 Sep 2005 11:19:33 -0700	[thread overview]
Message-ID: <508740000.1126117173@flay> (raw)
In-Reply-To: <Pine.LNX.4.62.0509070838240.21170@schroedinger.engr.sgi.com>

>> > Anticipatory prefaulting raises the highest fault rate obtainable three-fold
>> > through gang scheduling faults but may allocate some pages to a task that are
>> > not needed.
>> 
>> IIRC that costed more than it saved, at least for forky workloads like a
>> kernel compile - extra cost in zap_pte_range etc. If things have changed
>> substantially in that path, I guess we could run the numbers again - has
>> been a couple of years.
> 
> Right. The costs come about through wrong anticipations installing useless 
> mappings. The patches that I posted have this feature off by default. Gang 
> scheduling can be enabled by modifying a value in /proc. But I guess the 
> approach is essentially dead unless others want this feature too. The 
> current page fault scalability approach should be fine for a couple of 
> years and who knows what direction mmu technology has taken then.

It would seem to depends on the locality of reference in the affected files.
Which implies to me that the locality of libc, etc probably sucks, though
we had a simple debug patch somewhere to print out a bitmap of which pages
are faulted in and which are not ... was somewhere, I'll see if I can find
it.

M.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2005-09-07 18:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-06 18:31 Christoph Lameter
2005-09-07 14:28 ` Martin J. Bligh
2005-09-07 15:42   ` Christoph Lameter
2005-09-07 18:19     ` Martin J. Bligh [this message]
2005-09-15 12:54 ` Pavel Machek

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=508740000.1126117173@flay \
    --to=mbligh@mbligh.org \
    --cc=akpm@osdl.org \
    --cc=clameter@engr.sgi.com \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nickpiggin@yahoo.com.au \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox