All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Mackall <mpm@selenic.com>
To: Jens Axboe <axboe@suse.de>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.1-rc1-tiny2
Date: Wed, 7 Jan 2004 12:50:40 -0600	[thread overview]
Message-ID: <20040107185039.GC18208@waste.org> (raw)
In-Reply-To: <20040107140640.GC16720@suse.de>

On Wed, Jan 07, 2004 at 03:06:40PM +0100, Jens Axboe wrote:
> On Mon, Jan 05 2004, Matt Mackall wrote:
> > This is the fourth release of the -tiny kernel tree. The aim of this
> > tree is to collect patches that reduce kernel disk and memory
> > footprint as well as tools for working on small systems. Target users
> > are things like embedded systems, small or legacy desktop folks, and
> > handhelds.
> > 
> > Latest release includes:
> >  - various compile fixes for last release
> >  - actually include Andi Kleen's bloat-o-meter this time
> >  - optional mempool removal
> 
> Your CONFIG_MEMPOOL is completely broken as you are no longer giving the
> same guarentees (you have no reserve at all). Might as well change it to
> CONFIG_DEADLOCK instead.

It's equivalent to a pool size of zero, yes, so deadlock odds are
significantly higher with some usage scenarios. I'll add a big fat
warning.

On the other hand, the existence of pre-allocated mempools can greatly
increase the likelihood of starvation, oom, and deadlock on the rest
of the system, especially as it becomes a greater percentage of the
total free memory on a small system. In other words, I had to cut this
corner to make running in 2M work with my config. When I merge
CONFIG_BLOCK, it'll be more generally useful.

For the sake of our other readers, I'll point out that mempool doesn't
intrinisically reduce deadlock odds to zero unless we have a hard
limit on requests in flight that's strictly less than pool size.

-- 
Matt Mackall : http://www.selenic.com : Linux development and consulting

  reply	other threads:[~2004-01-07 18:50 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-06  5:48 2.6.1-rc1-tiny2 Matt Mackall
2004-01-06  6:33 ` 2.6.1-rc1-tiny2 Nick Piggin
2004-01-06  6:46   ` 2.6.1-rc1-tiny2 Matt Mackall
2004-01-06  7:08     ` 2.6.1-rc1-tiny2 Nick Piggin
2004-01-10  0:46       ` 2.6.1-rc1-tiny2 Adrian Bunk
2004-01-10  0:50         ` [0/4] better i386 CPU selection Adrian Bunk
2004-01-10  0:52         ` [1/4] " Adrian Bunk
2004-01-10 11:04           ` Wichert Akkerman
2004-01-11  3:13             ` Adrian Bunk
2004-01-14 20:49               ` [-mm patch] " Adrian Bunk
2004-01-16 19:15           ` [1/4] " cliff white
2004-01-16 19:32             ` Richard B. Johnson
2004-01-17  0:01               ` Andrew Morton
2004-01-17  2:57                 ` Adrian Bunk
2004-01-19 15:14                   ` John Stoffel
2004-01-19 23:42                     ` Nick Piggin
2004-01-17  2:15               ` Adrian Bunk
2004-01-17  9:13                 ` Robert Schwebel
2004-01-20 22:10                   ` Adrian Bunk
2004-01-20 22:31                     ` Richard B. Johnson
2004-01-20 22:47                     ` George Anzinger
2004-01-17 10:01                 ` aeriksson
2004-01-10  0:57         ` [2/4] move "struct movsl_mask movsl_mask" to usercopy.c Adrian Bunk
2004-01-10  0:57         ` [3/4] proof of concept: make arch/i386/kernel/cpu/Makefile CPU specific Adrian Bunk
2004-01-10  0:58         ` [4/4] proof of concept: make arch/i386/kernel/cpu/mtrr/Makefile " Adrian Bunk
2004-01-10 22:14         ` 2.6.1-rc1-tiny2 Matt Mackall
2004-01-12  2:20           ` 2.6.1-rc1-tiny2 Nick Piggin
2004-01-07 14:06 ` 2.6.1-rc1-tiny2 Jens Axboe
2004-01-07 18:50   ` Matt Mackall [this message]
2004-01-07 19:27     ` 2.6.1-rc1-tiny2 Mitchell Blank Jr
2004-01-07 20:10       ` 2.6.1-rc1-tiny2 Matt Mackall
2004-01-07 21:41         ` 2.6.1-rc1-tiny2 Trond Myklebust
2004-01-07 21:10     ` 2.6.1-rc1-tiny2 Jens Axboe
2004-01-07 21:30       ` 2.6.1-rc1-tiny2 Matt Mackall

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=20040107185039.GC18208@waste.org \
    --to=mpm@selenic.com \
    --cc=axboe@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    /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.