From: Matt Mackall <mpm@selenic.com>
To: Mitchell Blank Jr <mitch@sfgoth.com>
Cc: Jens Axboe <axboe@suse.de>, linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.1-rc1-tiny2
Date: Wed, 7 Jan 2004 14:10:56 -0600 [thread overview]
Message-ID: <20040107201056.GE18208@waste.org> (raw)
In-Reply-To: <20040107192732.GA13240@gaz.sfgoth.com>
On Wed, Jan 07, 2004 at 11:27:33AM -0800, Mitchell Blank Jr wrote:
> Matt Mackall wrote:
> > When I merge
> > CONFIG_BLOCK, it'll be more generally useful.
>
> Maybe it would make more sense to have CONFIG_MEMPOOL=n just remove
> the mempool API entirely and have it imply CONFIG_BLOCK=n, CONFIG_NFS_FS=n,
> and CONFIG_NFSD=n? Just a thought.
NFS is a good example of why the guarantees of mempool are being
overstated - it still needs to allocate SKBs to make progress and
preallocating a pool for other data structures can make that fail
where it otherwise might not. The pool size for NFS (32) is also
completely arbitrary as far as I can tell.
> It seems like a reasonalbe thing to omit for some tiny configs that don't
> need it, but if the API is provided it should probably work as expected.
The API _does_ work. It was a best effort with buffering before, it's
a best effort without buffering now.
--
Matt Mackall : http://www.selenic.com : Linux development and consulting
next prev parent reply other threads:[~2004-01-07 20:11 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 ` 2.6.1-rc1-tiny2 Matt Mackall
2004-01-07 19:27 ` 2.6.1-rc1-tiny2 Mitchell Blank Jr
2004-01-07 20:10 ` Matt Mackall [this message]
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=20040107201056.GE18208@waste.org \
--to=mpm@selenic.com \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mitch@sfgoth.com \
/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.