All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Jeff Moyer <jmoyer@redhat.com>,
	linux-kernel@vger.kernel.org, akpm@linux-foundation.org
Subject: Re: [PATCH 2/2] cfq-iosched: get rid of the need for __GFP_FAIL in cfq_find_alloc_queue()
Date: Thu, 9 Jul 2009 19:38:23 +0200	[thread overview]
Message-ID: <20090709173823.GN23611@kernel.dk> (raw)
In-Reply-To: <20090709154446.GD30832@redhat.com>

On Thu, Jul 09 2009, Vivek Goyal wrote:
> On Sat, Jun 27, 2009 at 08:26:17PM +0200, Jens Axboe wrote:
> > On Fri, Jun 26 2009, Jeff Moyer wrote:
> > > Jens Axboe <jens.axboe@oracle.com> writes:
> > > 
> > > > Setup an emergency fallback cfqq that we allocate at IO scheduler init
> > > > time. If the slab allocation fails in cfq_find_alloc_queue(), we'll just
> > > > punt IO to that cfqq instead. This ensures that cfq_find_alloc_queue()
> > > > never fails without having to ensure free memory.
> > > >
> > > > Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
> > > > ---
> > > >  block/cfq-iosched.c |  124 +++++++++++++++++++++++++++-----------------------
> > > >  1 files changed, 67 insertions(+), 57 deletions(-)
> > > >
> > > > diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
> > > > index c760ae7..91e7e0b 100644
> > > > --- a/block/cfq-iosched.c
> > > > +++ b/block/cfq-iosched.c
> > > > +	/*
> > > > +	 * Fallback dummy cfqq for extreme OOM conditions
> > > > +	 */
> > > > +	struct cfq_queue oom_cfqq;
> > > 
> > > OK, so you're embedding a cfqq into the cfqd.  That's 136 bytes, so I
> > > guess that's not too bad.
> > > 
> > > > +	/*
> > > > +	 * Our fallback cfqq if cfq_find_alloc_queue() runs into OOM issues.
> > > > +	 * Grab a permanent reference to it, so that the normal code flow
> > > > +	 * will not attempt to free it.
> > > > +	 */
> > > > +	cfq_init_cfqq(cfqd, &cfqd->oom_cfqq, 1, 0);
> > > > +	atomic_inc(&cfqd->oom_cfqq.ref);
> > > > +
> > > 
> > > I guess this is so we never try to free it, good.  ;)
> > > 
> > > One issue I have with this patch is that, if a task happens to run into
> > > this condition, there is no way out.  It will always have the oom_cfqq
> > > as it's cfqq.  Can't we fix that if we recover from the OOM condition?
> > 
> > Yeah, I fixed that about an hour after posting the patches. See:
> > 
> > http://git.kernel.dk/?p=linux-2.6-block.git;a=commit;h=0370bc158cb1d5faa4b8a38c0de3211f0fd5bd64
> > 
> 
> Hi Jens,
> 
> I think above patch might not fix the issue of an oom_cfqq getting stuck
> with an io context. The reason being that once we allocate the cfqq, it
> will be cached in cic and once next request comes, we will retrieve it
> from cic and never call cfq_get_queue()/cfq_find_alloc_queue().
> 
> I think we probably need to do cfqq == oom_cfqq check in cfq_set_request()
> also.

Yes good catch, this is needed too!  Can you please send as a "real"
patch with signed-off-by added? Thanks!

-- 
Jens Axboe


  reply	other threads:[~2009-07-09 17:38 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-26  9:05 [PATCH 0/2] cfq-iosched: get rid of __GFP_NOFAIL Jens Axboe
2009-06-26  9:05 ` [PATCH 1/2] cfq-iosched: move cfqq initialization out of cfq_find_alloc_queue() Jens Axboe
2009-06-26 16:09   ` Jeff Moyer
2009-06-26  9:05 ` [PATCH 2/2] cfq-iosched: get rid of the need for __GFP_FAIL in cfq_find_alloc_queue() Jens Axboe
2009-06-26 16:25   ` Jeff Moyer
2009-06-27 18:26     ` Jens Axboe
2009-06-29 13:46       ` Jeff Moyer
2009-06-29 17:34         ` Jens Axboe
2009-06-29 17:44           ` Jeff Moyer
2009-06-29 17:48             ` Jens Axboe
2009-07-09 15:44       ` Vivek Goyal
2009-07-09 17:38         ` Jens Axboe [this message]
2009-07-09 19:59           ` Vivek Goyal
2009-07-09 20:15             ` Jens Axboe
2009-07-01  9:28   ` Shan Wei
2009-07-01  9:32     ` Jens Axboe
2009-07-02  0:49       ` Shan Wei
2009-07-02  6:33         ` Jens Axboe
2009-06-26 16:05 ` [PATCH 0/2] cfq-iosched: get rid of __GFP_NOFAIL 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=20090709173823.GN23611@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=jmoyer@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vgoyal@redhat.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 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.