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: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC] My research agenda for 2.7
Date: Fri, 27 Jun 2003 14:00:42 +0100 (IST)	[thread overview]
Message-ID: <Pine.LNX.4.53.0306271345330.14677@skynet> (raw)
In-Reply-To: <200306270222.27727.phillips@arcor.de>

On Fri, 27 Jun 2003, Daniel Phillips wrote:

> On Thursday 26 June 2003 22:01, Mel Gorman wrote:
> > I think that finding pages like this together is unlikely, especially if
> > the system has been running a long time. In the worst case you will have
> > every easily-moved page adjactent to a near-impossible-to-move page.
>
> I addressed that in my previous post: "Most slab pages are hard to move
> ... we could just tell slab to use its own biggish chunks of memory,
> which it can play in as it sees fit".

Ah, ok, sorry, I missed that but it wouldn't be the first time I missed
something. It was just a few days ago I wrote a pile of material on the
new buddy allocator as part of a publication and still missed that the
order of pages can be identified because of compound pages, thanks Andrew.

> > I also wonder if moving kernel pages is really worth the hassle.
>
> That's the question of course.  The benefit is getting rid of high order
> allocation failures, and gaining some confidence that larger filesystem
> blocksizes will work reliably, however the workload evolves.

I'm still working on 2.6 documentation which I expect will be published in
a few months. When I get that written, I'll look into seeing what can be
done with VM Regress to calculate fragmentation and to see how often do
high order allocations actually fail. It might help determine where
defragging is most needed.

IIRC, Martin J. Bligh had a patch which displayed information about the
buddy allocator freelist so that will probably be the starting point. From
there, it should be handy enough to see how intermixed are kernel page
allocations with user allocations. It might turn out that kernel pages
tend to be clustered together anyway.

> > If order0 pages were in slab, the whole searching problem becomes trivial
> > (just go to the relevant cache and scan the slabs).
>
> You might want to write a separate [rfc] to describe your idea.  For one
> thing, I don't see why you'd want to use slab for that.
>

You're right, I will need to write a proper RFC one way or the other. 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.

Anyway, as I know I won't be coding any time soon due to writing docs,
I'll shut up for the moment :-)

-- 
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-27 13:00 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 [this message]
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
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.0306271345330.14677@skynet \
    --to=mel@csn.ul.ie \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --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