From: Paul Jackson <pj@sgi.com>
To: Arjan van de Ven <arjan@intel.linux.com>
Cc: linux-kernel@vger.kernel.org, ak@suse.de, akpm@osdl.org
Subject: Re: [Patch 3/3] prepopulate/cache cleared pages
Date: Thu, 23 Feb 2006 10:25:48 -0800 [thread overview]
Message-ID: <20060223102548.17ce2184.pj@sgi.com> (raw)
In-Reply-To: <1140686994.4672.4.camel@laptopd505.fenrus.org>
Just a random idea, offered with little real understanding
of what's going on ...
Instead of a per-task clear page, how about a per-cpu clear page,
or short queue of clear pages?
This lets the number of clear pages be throttled to whatever
is worth it. And it handles such cases as a few threads using
the clear pages rapidly, while many other threads don't need any,
with a much higher "average usefulness" per clear page (meaning
the average time a cleared page sits around wasting memory prior
to its being used is much shorter.)
Some locking would still be needed, but per-cpu locking is
a separate, quicker beast than something like mmap_sem.
Mind you, I am not commenting one way or the other on whether any
of this is a good idea. Not my expertise ...
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
next prev parent reply other threads:[~2006-02-23 18:25 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-23 9:17 [Patch 0/3] threaded mmap tweaks Arjan van de Ven
2006-02-23 9:29 ` [Patch 3/3] prepopulate/cache cleared pages Arjan van de Ven
2006-02-23 9:41 ` Andi Kleen
2006-02-23 12:41 ` Ingo Molnar
2006-02-23 13:06 ` Andi Kleen
2006-02-23 13:15 ` Nick Piggin
2006-02-23 13:29 ` Ingo Molnar
2006-02-24 6:36 ` Nick Piggin
2006-02-24 6:49 ` Ingo Molnar
2006-02-24 7:01 ` Nick Piggin
2006-02-24 12:33 ` Andi Kleen
2006-02-24 12:55 ` Hugh Dickins
2006-02-24 9:15 ` Arjan van de Ven
2006-02-24 9:26 ` Nick Piggin
2006-02-24 12:27 ` Andi Kleen
2006-02-24 15:31 ` Andrea Arcangeli
2006-02-25 16:48 ` Nick Piggin
2006-02-25 17:22 ` Nick Piggin
2006-02-28 22:30 ` Pavel Machek
2006-02-23 18:25 ` Paul Jackson [this message]
2006-02-23 9:30 ` [Patch 2/3] fast VMA recycling Arjan van de Ven
2006-02-23 9:42 ` Andi Kleen
2006-02-23 9:48 ` Arjan van de Ven
2006-02-23 10:05 ` Andi Kleen
2006-02-23 10:15 ` Arjan van de Ven
2006-02-23 11:00 ` Andi Kleen
2006-02-23 11:22 ` Arjan van de Ven
2006-02-23 11:57 ` Andi Kleen
2006-02-24 18:52 ` Christoph Hellwig
2006-02-24 19:05 ` Andi Kleen
2006-02-24 19:09 ` Christoph Hellwig
2006-02-23 16:37 ` Benjamin LaHaise
-- strict thread matches above, loose matches on Subject: below --
2006-02-23 20:02 [Patch 3/3] prepopulate/cache cleared pages Chuck Ebbert
2006-02-23 21:10 Chuck Ebbert
2006-02-23 21:18 ` Arjan van de Ven
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=20060223102548.17ce2184.pj@sgi.com \
--to=pj@sgi.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=arjan@intel.linux.com \
--cc=linux-kernel@vger.kernel.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.