From: Jens Axboe <axboe@suse.de>
To: "Adam J. Richter" <adam@yggdrasil.com>
Cc: akpm@zip.com.au, linux-kernel@vger.kernel.org
Subject: Re: bio_chain: proposed solution for bio_alloc failure and large IO simplification
Date: Sat, 15 Jun 2002 11:00:15 +0200 [thread overview]
Message-ID: <20020615090015.GA5869@suse.de> (raw)
In-Reply-To: <200206150852.BAA00805@adam.yggdrasil.com>
On Sat, Jun 15 2002, Adam J. Richter wrote:
> Jens Axboe wrote:
> >The I/O path allocations all use GFP_NOIO (or GFP_NOFS), which all have
> >__GFP_WAIT set. So the bio allocations will try normal allocation first,
> >then fall back to the bio pool. If the bio pool is also empty, we will
> >block waiting for entries to be freed there. So there never will be a
> >failure.
>
> I did not realize that allocation with __GFP_WAIT was guaranteed
> to _never_ fail.
See the mempool implementation. Even before bio used mempool, it used
the exact same logic to make sure it never fails. Basically the
heuristic in both cases is:
repeat:
bio = normal_alloc
if (bio)
return bio
bio = get_from_pool
if (bio)
return bio
if (gfp_mask & __GFP_WAIT)
start disk i/o
goto repeat;
> Even so, if __GFP_WAIT never fails, then it can deadlock (for
> example, some other device driver has a memory leak). Under a
> scheme like bio_chain (provided that it is changed not to call a
> memory allocator that can deadlock), the only way you deadlock is
> if there really is deadlock bug in the lower layers that process
> the underlying request.
This whole dead lock debate has been done to death before, I suggest you
find the mempool discussions in the lkml archives from the earlier 2.5
series. Basically we maintain deadlock free allocation although we never
fail allocs by saying that a single bio allocation is short lived (or
at least not held indefinetely). That plus a reserve of XX bios makes
sure that someone will always return a bio to the pool sooner or later
and at least the get_from_pool alloc above will succeed sooner or later
even if vm pressure is ridicilous.
--
Jens Axboe
next prev parent reply other threads:[~2002-06-15 9:00 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-15 8:52 bio_chain: proposed solution for bio_alloc failure and large IO simplification Adam J. Richter
2002-06-15 9:00 ` Jens Axboe [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-06-15 20:24 Adam J. Richter
2002-06-17 6:37 ` Jens Axboe
2002-06-15 20:01 Adam J. Richter
2002-06-15 20:22 ` Andrew Morton
2002-06-15 10:30 Adam J. Richter
2002-06-15 19:50 ` Andrew Morton
2002-06-17 6:36 ` Jens Axboe
2002-06-17 7:09 ` Andrew Morton
2002-06-15 9:10 Adam J. Richter
2002-06-15 9:14 ` Jens Axboe
2002-06-15 8:45 Adam J. Richter
2002-06-15 8:50 ` Jens Axboe
2002-06-15 4:38 Adam J. Richter
2002-06-15 0:22 Adam J. Richter
2002-06-14 23:39 Adam J. Richter
2002-06-14 23:58 ` Andrew Morton
2002-06-15 1:38 ` Oliver Xymoron
2002-06-15 7:55 ` Jens Axboe
2002-06-14 16:52 Adam J. Richter
2002-06-14 23:00 ` Andrew Morton
2002-06-14 23:29 ` William Lee Irwin III
2002-06-14 23:38 ` Andrew Morton
2002-06-15 7:55 ` Jens Axboe
2002-06-14 1:56 Adam J. Richter
2002-06-14 2:24 ` Andreas Dilger
2002-06-14 14:57 ` Jens Axboe
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=20020615090015.GA5869@suse.de \
--to=axboe@suse.de \
--cc=adam@yggdrasil.com \
--cc=akpm@zip.com.au \
--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.