From: Steven Whitehouse <steve@gw.chygwyn.com>
To: ptb@it.uc3m.es
Cc: alan@lxorguk.ukuu.org.uk, chen_xiangping@emc.com,
linux-kernel@vger.kernel.org (linux kernel)
Subject: Re: Kernel deadlock using nbd over acenic driver
Date: Thu, 16 May 2002 09:04:31 +0100 (BST) [thread overview]
Message-ID: <200205160804.JAA24761@gw.chygwyn.com> (raw)
In-Reply-To: <200205160515.g4G5F0I29175@oboe.it.uc3m.es> from "Peter T. Breuer" at May 16, 2002 07:15:00 AM
Hi,
[snip]
>
> I don't see any reason to introduce a second flag to say when a flag
> has been set .. Initial reports are that symptoms go away when
>
> current->flags |= PF_MEMALLOC;
>
> is set in the process about to do networking (and unset afterwards).
>
> There will be more news later today. I believe that this will remove
> deadlock against VM for tcp buffers, but I don't believe it will
> stop deadlocks against "nothing", when we simply are out of buffers.
> The only thing that can do that is reserved memory for the socket.
> Any pointers?
>
> Peter
>
The reason for adding the second flag is that I suspect that nbd_send_req()
can be called by processes which already have PF_MEMALLOC set, in which case
we don't want to alter that. The "priority inversion" that I mentioned occurs
when you get processes without PF_MEMALLOC set calling nbd_send_req() as when
they call through to page_alloc.c:__alloc_pages() they won't use any memory
once the free pages hits the min mark even though there is memory available
(see the code just before and after the rebalance label).
Once one process has started sleeping waiting for memory in nbd_send_req()
thats is, since tx_lock prevents any further writeouts until the sleeping
process has completed. Unfortunately this has to be the case in order to
ensure that nbd's requests are sent atomically.
So rather than reserve memory specifically for sockets, in effect the
min free pages for each zone place a limit on what "normal" allocations
may use as a maximum. This is fine provided allocations in the write out
path are not "normal" as well, but able to use whatever they need. At first
I thought "we only need to set PF_MEMALLOC if we are writing" but in fact
we have to set it for reads too so that reads don't block writes I think.
There is a difference though between preventing the deadlock and adjusting
the system so that we get the maximum performance, so it will be interesting
to see whether we ought to adjust the min free pages figure in order to
get higher performance, or whether its ok as it is.
I'm not sure yet that the PF_MEMALLOC change I described actually fixes the
problem either, although it should make things a lot better. Thats
something else for further investigation.
Steve.
next prev parent reply other threads:[~2002-05-16 8:24 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-15 17:43 Peter T. Breuer
2002-05-15 19:43 ` Steven Whitehouse
2002-05-16 5:15 ` Peter T. Breuer
2002-05-16 8:04 ` Steven Whitehouse [this message]
2002-05-16 8:49 ` Peter T. Breuer
-- strict thread matches above, loose matches on Subject: below --
2002-05-16 22:54 Peter T. Breuer
2002-05-17 8:44 ` Steven Whitehouse
2002-05-23 13:21 ` Peter T. Breuer
2002-05-24 10:11 ` Steven Whitehouse
2002-05-24 11:43 ` Peter T. Breuer
2002-05-24 13:28 ` Steven Whitehouse
2002-05-24 15:54 ` Peter T. Breuer
2002-05-27 13:04 ` Steven Whitehouse
2002-05-27 19:51 ` Peter T. Breuer
2002-05-27 13:44 ` Pavel Machek
2002-05-29 10:51 ` Peter T. Breuer
2002-05-29 11:21 ` Pavel Machek
2002-05-29 12:10 ` Peter T. Breuer
2002-05-29 13:24 ` Jens Axboe
2002-06-01 21:13 ` Peter T. Breuer
2002-06-05 8:48 ` Steven Whitehouse
2002-06-02 6:39 ` Pavel Machek
[not found] <3CE40A77.22C74DC1@zip.com.au>
2002-05-16 20:28 ` Peter T. Breuer
2002-05-16 13:18 chen, xiangping
2002-05-15 21:43 Peter T. Breuer
2002-05-16 8:33 ` Steven Whitehouse
2002-05-15 16:01 Peter T. Breuer
2002-05-14 17:42 chen, xiangping
2002-05-14 17:36 chen, xiangping
2002-05-14 18:02 ` Alan Cox
2002-05-14 16:07 chen, xiangping
2002-05-14 16:32 ` Steven Whitehouse
2002-05-14 16:48 ` Alan Cox
2002-05-15 22:31 ` Oliver Xymoron
2002-05-16 5:10 ` Peter T. Breuer
2002-05-16 5:19 ` Peter T. Breuer
2002-05-16 14:29 ` Oliver Xymoron
2002-05-16 15:35 ` Peter T. Breuer
2002-05-16 16:22 ` Oliver Xymoron
2002-05-16 16:45 ` Peter T. Breuer
2002-05-16 16:35 ` Steven Whitehouse
2002-05-17 7:01 ` Peter T. Breuer
2002-05-17 9:26 ` Steven Whitehouse
2002-05-14 15:05 chen, xiangping
2002-05-14 15:11 ` Jes Sorensen
2002-05-10 15:39 chen, xiangping
2002-05-10 15:02 chen, xiangping
2002-05-10 15:11 ` Steven Whitehouse
2002-05-14 14:58 ` Jes Sorensen
2002-05-06 15:05 chen, xiangping
2002-05-07 8:15 ` Steven Whitehouse
2002-05-06 2:26 chen, xiangping
2002-05-06 8:45 ` Steven Whitehouse
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=200205160804.JAA24761@gw.chygwyn.com \
--to=steve@gw.chygwyn.com \
--cc=Steve@ChyGwyn.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=chen_xiangping@emc.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ptb@it.uc3m.es \
/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
all inboxes | Powered by JetHome®