From: "Stefan Bader" <Stefan.Bader@de.ibm.com>
To: device-mapper development <dm-devel@redhat.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>,
Stefan Weinhuber <wein@de.ibm.com>,
linux-mm@kvack.org, Daniel Kobras <kobras@linux.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Alasdair G Kergon <agk@redhat.com>
Subject: Re: [dm-devel] Re: [PATCH] dm: Fix deadlock under high i/o load in raid1 setup.
Date: Thu, 16 Aug 2007 09:09:24 +0200 [thread overview]
Message-ID: <5201e28f0708160009n2ef3ffc8ie4ce4133cc9c3a13@mail.gmail.com> (raw)
In-Reply-To: <20070815201029.fb965871.akpm@linux-foundation.org>
>>> How come my computer is the only one with a reply button?
Hey, I've got one. ;-)
2007/8/16, Andrew Morton <akpm@linux-foundation.org>:
> On Thu, 16 Aug 2007 01:59:56 +0200 Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
>
> > > So yes, I'd say this is a bug in DM.
> > >
> > > Also, __rh_alloc() is called under read_lock(), via __rh_find(). If
> > > __rh_alloc()'s mempool_alloc() fails, it will perform a sleeping allocation
> > > under read_lock(), which is deadlockable and will generate might_sleep()
> > > warnings
> >
> > The read_lock() is unlocked at the beginning of the function.
>
> Oh, OK. Looks odd, but whatever.
>
The major trick, if I am not wrong, is to use GFP_ATOMIC on that
mempool_alloc(). This prevents the sleeping allocation but fails, if
memory as well as the pool is exhausted.
>
> It'd be better to fix the kmirrord design so that it can use mempools
> properly. One possible way of doing that might be to notice when mempool
> exhaustion happens, submit whatever IO is thus-far buffered up and then do
> a sleeping mempool allocation, to wait for that memory to come free (via IO
> completion).
>
> That would be a bit abusive of the mempool intent though. A more idiomatic
> fix would be to change kmirrord so that it no longer can consume all of the
> mempool's reserves without having submitted any I/O (which is what I assume
> it is doing).
>
The problem is, that only the same thread, that allocates from the
pool would return memory back. This would be done before the new
allocations. But, if there is very high memory pressure, the pool
might get drained in the allocation cycle. Then mempool_alloc() waits
to be woken from mempool_free(). And this never happens, since the
thread will be stuck. So I guess the fix would be to somehow separate
the allocation and freeing functionality. If I remember correctly
back, the patch was always seen as "not quite correctly, but seems to
work". However, due to lack of time, nobody ever came up with a better
solution.
Stefan
--
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:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2007-08-16 7:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-13 11:33 Heiko Carstens
2007-08-15 22:56 ` Andrew Morton
2007-08-15 23:59 ` Heiko Carstens
2007-08-16 3:10 ` Andrew Morton
2007-08-16 7:09 ` Stefan Bader [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=5201e28f0708160009n2ef3ffc8ie4ce4133cc9c3a13@mail.gmail.com \
--to=stefan.bader@de.ibm.com \
--cc=agk@redhat.com \
--cc=dm-devel@redhat.com \
--cc=heiko.carstens@de.ibm.com \
--cc=kobras@linux.de \
--cc=linux-mm@kvack.org \
--cc=torvalds@linux-foundation.org \
--cc=wein@de.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox