From: Jeff Moyer <jmoyer@redhat.com>
To: Lukas Czerner <lczerner@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-kernel@vger.kernel.org, Dave Chinner <dchinner@redhat.com>
Subject: Re: [PATCH] loop: Limit the number of requests in the bio list
Date: Mon, 01 Oct 2012 12:52:19 -0400 [thread overview]
Message-ID: <x49ipaukud8.fsf@segfault.boston.devel.redhat.com> (raw)
In-Reply-To: <1348767205-17230-1-git-send-email-lczerner@redhat.com> (Lukas Czerner's message of "Thu, 27 Sep 2012 13:33:25 -0400")
Lukas Czerner <lczerner@redhat.com> writes:
> Currently there is not limitation of number of requests in the loop bio
> list. This can lead into some nasty situations when the caller spawns
> tons of bio requests taking huge amount of memory. This is even more
> obvious with discard where blkdev_issue_discard() will submit all bios
> for the range and wait for them to finish afterwards. On really big loop
> devices this can lead to OOM situation as reported by Dave Chinner.
>
> With this patch we will wait in loop_make_request() if the number of
> bios in the loop bio list would exceed 'nr_requests' number of requests.
> We'll wake up the process as we process the bios form the list.
I think you might want to do something similar to what is done for
request_queues by implementing a congestion on and off threshold. As
Jens writes in this commit (predating the conversion to git):
Author: Jens Axboe <axboe@suse.de>
Date: Wed Nov 3 15:47:37 2004 -0800
[PATCH] queue congestion threshold hysteresis
We need to open the gap between congestion on/off a little bit, or
we risk burning many cycles continually putting processes on a wait
queue only to wake them up again immediately. This was observed with
CFQ at least, which showed way excessive sys time.
Patch is from Arjan.
Signed-off-by: Jens Axboe <axboe@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
If you feel this isn't necessary, then I think you at least need to
justify it with testing. Perhaps Jens can shed some light on the exact
workload that triggered the pathological behaviour.
Cheers,
Jeff
next prev parent reply other threads:[~2012-10-01 16:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-27 17:33 Lukas Czerner
2012-10-01 16:52 ` Jeff Moyer [this message]
2012-10-02 8:52 ` Lukáš Czerner
2012-10-02 19:59 ` Dave Chinner
2012-10-03 14:30 ` Jeff Moyer
2012-10-03 15:01 ` Lukáš Czerner
2012-10-03 15:05 ` Jeff Moyer
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=x49ipaukud8.fsf@segfault.boston.devel.redhat.com \
--to=jmoyer@redhat.com \
--cc=axboe@kernel.dk \
--cc=dchinner@redhat.com \
--cc=lczerner@redhat.com \
--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 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®