linux-kernel - Re: [PATCHSET] blkcg: unify blkgs for different policies

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120202204342.GB30258@redhat.com>
Date:	Thu, 2 Feb 2012 15:43:42 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	axboe@...nel.dk, ctalbott@...gle.com, rni@...gle.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCHSET] blkcg: unify blkgs for different policies

On Thu, Feb 02, 2012 at 12:36:09PM -0800, Tejun Heo wrote:
> Hello,
> 
> On Thu, Feb 02, 2012 at 02:29:58PM -0500, Vivek Goyal wrote:
> > On Wed, Feb 01, 2012 at 01:19:05PM -0800, Tejun Heo wrote:
> > 
> > [..]
> > > 
> > > * use unified stats updated under queue lock and drop percpu stats
> > >   which should fix locking / context bug across percpu allocation.
> > 
> > Does that mean that stat updation will happen under queue lock even if
> > there are no throttling rules? That will introduce extra queue lock on
> > fast path those who have throttling compiled in but are not using (common
> > case for distributions).
> 
> No, I don't think extra locking would be necessary at all.  We end up
> grabbing queue_lock anyway.  It's just the matter of where to update
> the stats.

What about bio based drivers? They might have their own internal locking
and not relying on queue lock. And conceptually, we first throttle the
bio, update the stats and then call into driver. So are you planning
to move blk_throtl_bio() call into request function of individual driver
to avoid taking queue lock twice.

In fact even for request based drivers, if bio is being merged onto
existing request on plug, we will not take any queue lock. So I am not
sure how would you avoid extra queue lock for this case.

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/