From: Daniel Phillips <phillips@arcor.de>
To: Mel Gorman <mel@csn.ul.ie>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC] My research agenda for 2.7
Date: Fri, 27 Jun 2003 16:41:06 +0200 [thread overview]
Message-ID: <200306271641.06771.phillips@arcor.de> (raw)
In-Reply-To: <Pine.LNX.4.53.0306271345330.14677@skynet>
On Friday 27 June 2003 15:00, Mel Gorman wrote:
> On Fri, 27 Jun 2003, Daniel Phillips wrote:
> I was thinking of using slabs because that way there wouldn't be need to
> scan all of mem_map, just a small number of slabs. I have no basis for
> this other than hand waving gestures though.
That's the right idea, it's just not necessary to use slab cache to achieve
it. Actually, to handle huge (hardware) pages efficiently, my first instinct
is to partition them into their own largish chunks as well, and allocate new
chunks as necessary. To get rid of a chunk (because freespace of that type
of chunk has fallen below some threshold) it has to be entirely empty, which
can be accomplished using the same move logic as for defragmentation.
You're right to be worried about intrusion of unmovable pages into regions
that are supposed to be defraggable. It's very easy for some random kernel
code to take a use count on a page and hang onto it forever, making the page
unmovable. My hope is that:
- This doesn't happen much
- Code that does that can be cleaned up
- Even when it happens it won't hurt much
- If all of the above fails, fix the api for the offending code or create
a new one
- If that fails too, give up.
Regards,
Daniel
--
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-27 14:41 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 [this message]
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
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=200306271641.06771.phillips@arcor.de \
--to=phillips@arcor.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
/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