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 15:30:14 -0600 [thread overview]
Message-ID: <20040107213014.GF18208@waste.org> (raw)
In-Reply-To: <20040107211045.GJ16720@suse.de>
> > 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.
>
> That's not true, depends entirely on usage. It's not a magic wand. And
> you don't need a hard limit, you only need progress guarentee.
Yes, definitely depends on usage.
> Typically just a single pre-allocated object can make you 100%
> deadlock free, if stacking is not involved. So for most cases, I
> think it would be much better if you just hard wired min_nr to 1,
> that would move you from 90% to 99% safe :-)
Sure, I've considered that. I'll put an option for that on my todo list.
--
Matt Mackall : http://www.selenic.com : Linux development and consulting
prev parent reply other threads:[~2004-01-07 21:31 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 ` 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 ` Matt Mackall [this message]
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=20040107213014.GF18208@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.