All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@arcor.de>
To: "Martin J. Bligh" <mbligh@aracnet.com>, 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 17:17:01 +0200	[thread overview]
Message-ID: <200306271717.01562.phillips@arcor.de> (raw)
In-Reply-To: <25700000.1056726277@[10.10.2.4]>

On Friday 27 June 2003 17:04, Martin J. Bligh wrote:
> Daniel Phillips <phillips@arcor.de> wrote (on Friday, June 27, 2003
> > Some allocation strategies may be statistically more
> > resistiant to fragmentation than others, but no allocator has been
> > invented, or ever will be, that can guarantee that terminal fragmentation
> > will never occur - only active defragmentation can provide such a
> > guarantee.
>
> Whilst I agree with that in principle, it's inevitably expensive. Thus
> whilst we may need to have that code, we should try to avoid using it ;-)

That's exactly the idea.  Active defragmentation is just a fallback to handle  
currently-unhandled corner cases.  A good, efficient allocator that resists 
fragmentation in the first place is still needed.

Regards,

Daniel


WARNING: multiple messages have this Message-ID (diff)
From: Daniel Phillips <phillips@arcor.de>
To: "Martin J. Bligh" <mbligh@aracnet.com>, 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 17:17:01 +0200	[thread overview]
Message-ID: <200306271717.01562.phillips@arcor.de> (raw)
In-Reply-To: <25700000.1056726277@[10.10.2.4]>

On Friday 27 June 2003 17:04, Martin J. Bligh wrote:
> Daniel Phillips <phillips@arcor.de> wrote (on Friday, June 27, 2003
> > Some allocation strategies may be statistically more
> > resistiant to fragmentation than others, but no allocator has been
> > invented, or ever will be, that can guarantee that terminal fragmentation
> > will never occur - only active defragmentation can provide such a
> > guarantee.
>
> Whilst I agree with that in principle, it's inevitably expensive. Thus
> whilst we may need to have that code, we should try to avoid using it ;-)

That's exactly the idea.  Active defragmentation is just a fallback to handle  
currently-unhandled corner cases.  A good, efficient allocator that resists 
fragmentation in the first place is still needed.

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>

  reply	other threads:[~2003-06-27 15:05 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-24 23:11 [RFC] My research agenda for 2.7 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 19:00     ` Daniel Phillips
2003-06-26 20:01     ` Mel Gorman
2003-06-26 20:01       ` Mel Gorman
2003-06-26 20:10       ` Andrew Morton
2003-06-26 20:10         ` Andrew Morton
2003-06-27  0:30       ` Daniel Phillips
2003-06-27  0:30         ` Daniel Phillips
2003-06-27 13:00         ` Mel Gorman
2003-06-27 13:00           ` Mel Gorman
2003-06-27 14:38           ` Martin J. Bligh
2003-06-27 14:38             ` Martin J. Bligh
2003-06-27 14:41           ` Daniel Phillips
2003-06-27 14:41             ` Daniel Phillips
2003-06-27 14:43           ` Martin J. Bligh
2003-06-27 14:43             ` Martin J. Bligh
2003-06-27 14:54             ` Daniel Phillips
2003-06-27 14:54               ` Daniel Phillips
2003-06-27 15:04               ` Martin J. Bligh
2003-06-27 15:04                 ` Martin J. Bligh
2003-06-27 15:17                 ` Daniel Phillips [this message]
2003-06-27 15:17                   ` Daniel Phillips
2003-06-27 15:22                   ` Mel Gorman
2003-06-27 15:22                     ` Mel Gorman
2003-06-27 15:50                     ` Daniel Phillips
2003-06-27 15:50                       ` Daniel Phillips
2003-06-27 16:00                       ` Daniel Phillips
2003-06-27 16:00                         ` Daniel Phillips
2003-06-29 19:25                         ` Mel Gorman
2003-06-29 19:25                           ` Mel Gorman
2003-06-28 21:06                           ` Daniel Phillips
2003-06-28 21:06                             ` Daniel Phillips
2003-06-29 21:26                             ` Mel Gorman
2003-06-29 21:26                               ` Mel Gorman
2003-06-28 21:54                               ` Daniel Phillips
2003-06-28 21:54                                 ` Daniel Phillips
2003-06-29 22:07                                 ` William Lee Irwin III
2003-06-29 22:07                                   ` William Lee Irwin III
2003-06-28 23:18                                   ` Daniel Phillips
2003-06-28 23:18                                     ` Daniel Phillips
2003-07-02 21:10           ` Mike Fedyk
2003-07-02 21:10             ` Mike Fedyk
2003-07-03  2:04             ` Larry McVoy
2003-07-03  2:04               ` Larry McVoy
2003-07-03  2:20               ` William Lee Irwin III
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=200306271717.01562.phillips@arcor.de \
    --to=phillips@arcor.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mbligh@aracnet.com \
    --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 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.