From: William Lee Irwin III <wli@holomorphy.com>
To: Daniel Phillips <phillips@arcor.de>
Cc: Mel Gorman <mel@csn.ul.ie>,
"Martin J. Bligh" <mbligh@aracnet.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC] My research agenda for 2.7
Date: Sun, 29 Jun 2003 15:07:56 -0700 [thread overview]
Message-ID: <20030629220756.GB26348@holomorphy.com> (raw)
In-Reply-To: <200306282354.43153.phillips@arcor.de>
On Sunday 29 June 2003 23:26, Mel Gorman wrote:
>> Thats where your defragger would need to kick in. The defragger would scan
>> at most MAX_DEFRAG_SCAN slabs belonging to the order0 userspace cache
>> where MAX_DEFRAG_SCAN is related to how urgent the request is. Select the
>> slab with the least objects in them and either:
>> a) Reclaim the pages by swapping them out or whatever
>> b) Copy the pages to another slab and update the page tables via rmap
>> Once the pages are copied from the selected slab, destroy it and you have
>> a large block of free pages.
On Sat, Jun 28, 2003 at 11:54:43PM +0200, Daniel Phillips wrote:
> Yes, now we're on the same page, so to speak. Personally, I don't have much
> interest in working on improving the allocator per se. I'd love to see
> somebody else take a run at that, and I will occupy myself with the gritty
> details of how to move pages without making the system crater.
This sounds like it's behind dependent on physically scanning slabs,
since one must choose slab pages for replacement on the basis of their
potential to restore contiguity, not merely "dump whatever's replaceable
and check how much got freed".
On Sunday 29 June 2003 23:26, Mel Gorman wrote:
>> The point which I am getting across, quite
>> badly, is that by having order0 pages in slab, you are guarenteed to be
>> able to quickly find a cluster of pages to move which will free up a
>> contiguous block of 2^MAX_ORDER pages, or at least 2^MAX_GFP_ORDER with
>> the current slab implementation.
On Sat, Jun 28, 2003 at 11:54:43PM +0200, Daniel Phillips wrote:
> I don't see that it's guaranteed, but I do see that organizing pages in
> slab-like chunks is a good thing to do - a close reading of my original
> response to you shows I was thinking about that.
> I also don't see that the slab cache in its current incarnation is the right
> tool for the job. It handles things that we just don't need to handle, such
> as objects of arbitary size and alignment. I'm sure you could make it work,
> but why not just tweak alloc_pages to know about chunks instead?
A larger question in my mind is what slabs have to do with this at all.
Slabs are for fixed-size allocations. These techniques are explicitly
oriented toward making user allocations more variable, not less.
-- wli
--
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:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2003-06-29 22:07 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-24 23:11 Daniel Phillips
2003-06-25 0:47 ` William Lee Irwin III
2003-06-25 1:07 ` Daniel Phillips
2003-06-25 1:10 ` William Lee Irwin III
2003-06-25 1:25 ` Daniel Phillips
2003-06-25 1:30 ` William Lee Irwin III
2003-06-25 9:29 ` Mel Gorman
2003-06-26 19:00 ` Daniel Phillips
2003-06-26 20:01 ` Mel Gorman
2003-06-26 20:10 ` Andrew Morton
2003-06-27 0:30 ` Daniel Phillips
2003-06-27 13:00 ` Mel Gorman
2003-06-27 14:38 ` Martin J. Bligh
2003-06-27 14:41 ` Daniel Phillips
2003-06-27 14:43 ` Martin J. Bligh
2003-06-27 14:54 ` Daniel Phillips
2003-06-27 15:04 ` Martin J. Bligh
2003-06-27 15:17 ` Daniel Phillips
2003-06-27 15:22 ` Mel Gorman
2003-06-27 15:50 ` Daniel Phillips
2003-06-27 16:00 ` Daniel Phillips
2003-06-29 19:25 ` Mel Gorman
2003-06-28 21:06 ` Daniel Phillips
2003-06-29 21:26 ` Mel Gorman
2003-06-28 21:54 ` Daniel Phillips
2003-06-29 22:07 ` William Lee Irwin III [this message]
2003-06-28 23:18 ` Daniel Phillips
2003-07-02 21:10 ` Mike Fedyk
2003-07-03 2:04 ` Larry McVoy
2003-07-03 2:20 ` William Lee Irwin III
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=20030629220756.GB26348@holomorphy.com \
--to=wli@holomorphy.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mbligh@aracnet.com \
--cc=mel@csn.ul.ie \
--cc=phillips@arcor.de \
/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