All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kent Overstreet <kmo@daterainc.com>
To: Shaohua Li <shli@kernel.org>
Cc: linux-kernel@vger.kernel.org, axboe@kernel.dk, hch@infradead.org
Subject: Re: [patch 1/2]percpu_ida: fix a live lock
Date: Mon, 6 Jan 2014 12:46:41 -0800	[thread overview]
Message-ID: <20140106204641.GB9037@kmo> (raw)
In-Reply-To: <20140105131300.GB4186@kernel.org>

On Sun, Jan 05, 2014 at 09:13:00PM +0800, Shaohua Li wrote:
> On Sat, Jan 04, 2014 at 01:08:04PM -0800, Kent Overstreet wrote:
> > On Tue, Dec 31, 2013 at 11:38:27AM +0800, Shaohua Li wrote:
> > > 
> > > steal_tags only happens when free tags is more than half of the total tags.
> > > This is too restrict and can cause live lock. I found one cpu has free tags,
> > > but other cpu can't steal (thread is bound to specific cpus), threads which
> > > wants to allocate tags are always sleeping. I found this when I run next patch,
> > > but this could happen without it I think.
> > > 
> > > I did performance test too with null_blk. Two cases (each cpu has enough percpu
> > > tags, or total tags are limited) haven't performance changes.
> > 
> > This doesn't appear to me to fix anything wrong with the current code
> > (and it'll hurt performance)
> 
> I suspects this hurts performance too, but it doesn't actually in my test.
> 
> > - we explicitly don't guarantee that all
> > the tags will be available for allocation at any given time, only half
> > of them. 
> 
> only half of the tags can be used? this is scaring. Of course we hope all tags
> are available.

No: that behaviour is explicitly documented and it's the behaviour we want.

There is an inherent performance tradeoff here between internal fragmentation
and performance: your patch tries to drive internal fragmentation to 0, but
under workloads that hit this, running on enough cores, this will have a VERY
high performance cost.

> > Can you explain more how this is being used where you're seeing
> > the issue? And I don't see the other patch in your patch series.
> 
> tasks are bound to specific cpus. And I saw one cpu has a lot of free (but less
> than half of total tags), but other cpus can't allocate tags, so I saw a live
> lock.

You're using it wrong - don't assume all nr_tags can be allocated. If you need
to guarantee that you'll always be able to allocate a certain number of tags,
you pass twice that to percpu_ida_init() instead.

Nacking this patch (and if you want me to look at it more you still to send me
the other patch in the series and show me your code that's using it).

  reply	other threads:[~2014-01-06 20:46 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-31  3:38 [patch 1/2]percpu_ida: fix a live lock Shaohua Li
2014-01-04 21:08 ` Kent Overstreet
2014-01-05 13:13   ` Shaohua Li
2014-01-06 20:46     ` Kent Overstreet [this message]
2014-01-06 20:52       ` Jens Axboe
2014-01-06 21:47         ` Kent Overstreet
2014-02-09 15:50           ` Alexander Gordeev
2014-02-10 10:32             ` Christoph Hellwig
2014-02-10 12:29               ` Alexander Gordeev
2014-02-10 15:49                 ` Alexander Gordeev
2014-02-10 16:16                   ` Christoph Hellwig
2014-02-10 16:26               ` Jens Axboe
2014-02-10 22:41                 ` Kent Overstreet
2014-02-10 23:06                   ` Jens Axboe
2014-02-11  9:12                     ` Christoph Hellwig
2014-02-11 14:42                       ` James Bottomley
2014-02-11 14:53                         ` Christoph Hellwig
2014-02-14 10:36                     ` Alexander Gordeev

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=20140106204641.GB9037@kmo \
    --to=kmo@daterainc.com \
    --cc=axboe@kernel.dk \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shli@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.