linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mel@csn.ul.ie>
To: Daniel Phillips <phillips@arcor.de>
Cc: "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 22:26:51 +0100 (IST)	[thread overview]
Message-ID: <Pine.LNX.4.53.0306292214160.11946@skynet> (raw)
In-Reply-To: <200306282306.59502.phillips@arcor.de>

On Sat, 28 Jun 2003, Daniel Phillips wrote:

> There's no question that that's the case today.  However, there are good
> reasons for using a largish filesystem blocksize, 16K for example, once it
> becomes possible to do so.

Fair enough. I am not very familiar with filesystems or why it would be
desirable to have a blocksize greater than a page size. I'd be grateful if
you'd recommend a good book, paper or documentation set that would
enlighten me.

> > Because they are so common in comparison to other orders, I
> > think that putting order0 in slabs of size 2^MAX_ORDER will make
> > defragmentation *so* much easier, if not plain simple, because you can
> > shuffle around order0 pages in the slabs to free up one slab which frees
> > up one large 2^MAX_ORDER adjacent block of pages.
>
> But how will you shuffle those pages around?
>

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. 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.

For kernel pages, it would get a lot more complicated but at least the
kernel pages would be clustered together in the order0 cache for kernel
pages.

-- 
Mel Gorman
--
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>

  reply	other threads:[~2003-06-29 21:26 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 [this message]
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=Pine.LNX.4.53.0306292214160.11946@skynet \
    --to=mel@csn.ul.ie \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mbligh@aracnet.com \
    --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