linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: axboe@kernel.dk, akpm@linux-foundation.org,
	linux-kernel@vger.kernel.org, dpshah@google.com,
	ctalbott@google.com, rni@google.com
Subject: Re: [PATCH 5/5] blkcg: remove blkio_group->stats_lock
Date: Fri, 9 Mar 2012 10:03:12 -0800	[thread overview]
Message-ID: <20120309180312.GC24890@google.com> (raw)
In-Reply-To: <20120309171523.GB7746@redhat.com>

Hey, Vivek.

On Fri, Mar 09, 2012 at 12:15:23PM -0500, Vivek Goyal wrote:
> On Thu, Mar 08, 2012 at 10:54:00AM -0800, Tejun Heo wrote:
> > With recent plug merge updates, all non-percpu stat updates happen
> > under queue_lock making stats_lock unnecessary to synchronize stat
> > updates.  The only synchronization necessary is stat reading, which
> > can be done using u64_stats_sync instead.
> > 
> > This patch removes blkio_group->stats_lock and adds
> > blkio_group_stats->syncp for reader synchronization.
> 
> Good to see stat_lock going away. That lock was confusing as we were doing
> updates under queue_lock anyway. One less lock to think about now.
> 
> This stat code is messy though. All time related stat, maintaining flags,
> dividing stats between read/write, sync/async. I think we are maintaining
> way too much of stat. (/me wished there was a way to get rid of some of
> the stats and make code simpler).

The biggest problem I'm having with the stat code is that it almost
mandates spaghettiness.  This stems both from the limitations of
cgroup files and the implementation.  blkcg needs to declare all
possible files upfront on creating cgroup directories, so it needs to
know all files which may be used by any policy implementation.  This
leads another layer of indirection in blkcg core and when a policy
wants to create a new file (including stat), it has to add it to the
blkcg core and then walk back.  This is inherently nasty.  I'm trying
to see whether cgroup can be updated to allow dynamic file
creation/removal so that policies can manage their own files instead
of having to dump everything into blkcg core.

Thanks.

-- 
tejun

      reply	other threads:[~2012-03-09 18:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-08 18:53 [PATCHSET] blkcg: fix percpu stat allocation and remove stats_lock, take#2 Tejun Heo
2012-03-08 18:53 ` [PATCH 1/5] blkcg: alloc per cpu stats from worker thread in a delayed manner Tejun Heo
2012-03-08 18:53 ` [PATCH 2/5] blkcg: don't use percpu for merged stats Tejun Heo
2012-03-08 18:53 ` [PATCH 3/5] blkcg: simplify stat reset Tejun Heo
2012-03-08 18:53 ` [PATCH 4/5] blkcg: restructure blkio_get_stat() Tejun Heo
2012-03-08 18:54 ` [PATCH 5/5] blkcg: remove blkio_group->stats_lock Tejun Heo
2012-03-09 17:15   ` Vivek Goyal
2012-03-09 18:03     ` Tejun Heo [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=20120309180312.GC24890@google.com \
    --to=tj@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=ctalbott@google.com \
    --cc=dpshah@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rni@google.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).