All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Randy Dunlap <randy.dunlap@oracle.com>
Cc: linux-kernel@vger.kernel.org, axboe@kernel.dk
Subject: Re: [PATCH 4/4] blkio: Recalculate the throttled bio dispatch time upon throttle limit change
Date: Tue, 28 Sep 2010 13:36:26 -0400	[thread overview]
Message-ID: <20100928173625.GD8950@redhat.com> (raw)
In-Reply-To: <20100928101641.a2791513.randy.dunlap@oracle.com>

On Tue, Sep 28, 2010 at 10:16:41AM -0700, Randy Dunlap wrote:
> On Tue, 28 Sep 2010 13:10:59 -0400 Vivek Goyal wrote:
> 
> > o Currently any cgroup throttle limit changes are processed asynchronousy and
> >   the change does not take affect till a new bio is dispatched from same group.
> > 
> > o It might happen that a user sets a redicuously low limit on throttling.
> >   Say 1 bytes per second on reads. In such cases simple operations like mount
> >   a disk can wait for a very long time.
> > 
> > o Once bio is throttled, there is no easy way to come out of that wait even if
> >   user increases the read limit later.
> > 
> > o This patch fixes it. Now if a user changes the cgroup limits, we recalculate
> >   the bio dispatch time according to new limits.
> > 
> > o Can't take queueu lock under blkcg_lock, hence after the change I wake
> >   up the dispatch thread again which recalculates the time. So there are some
> >   variables being synchronized across two threads without lock and I had to
> >   make use of barriers. Hoping I have used barriers correctly. Any review of
> >   memory barrier code especially will help.
> 
> 
> Hi,
> Has this report been addressed/fixed?
> 

Hi Randy,

No. I was not aware of it. Thanks for bringing it to my notice. I will look
into it.

Vivek

> 
> on i386:
> 
> blk-throttle.c:(.text+0x1abb8): undefined reference to `__udivdi3'
> blk-throttle.c:(.text+0x1b1dc): undefined reference to `__udivdi3'
> 
> 
> on linux-next 2010-0924 and 2010-0927.
> 
> ---
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***

      reply	other threads:[~2010-09-28 17:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-28 17:10 [PATCH] Various block throttling fixes Vivek Goyal
2010-09-28 17:10 ` [PATCH 1/4] blkio: Do not export throttle files if CONFIG_BLK_DEV_THROTTLING=n Vivek Goyal
2010-09-28 17:10 ` [PATCH 2/4] blkio: deletion of a cgroup was causes oops Vivek Goyal
2010-09-28 17:10 ` [PATCH 3/4] blkio: Add root group to td->tg_list Vivek Goyal
2010-09-28 17:10 ` [PATCH 4/4] blkio: Recalculate the throttled bio dispatch time upon throttle limit change Vivek Goyal
2010-09-28 17:16   ` Randy Dunlap
2010-09-28 17:36     ` Vivek Goyal [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=20100928173625.GD8950@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=randy.dunlap@oracle.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.