linux-kernel - Re: [RFC PATCH 00/14] blk-throttle: lockless bio processing for no throttle rule group

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20110519184431.GE12600@redhat.com>
Date:	Thu, 19 May 2011 14:44:31 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Jens Axboe <jaxboe@...ionio.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"dpshah@...gle.com" <dpshah@...gle.com>
Subject: Re: [RFC PATCH 00/14] blk-throttle: lockless bio processing for no
 throttle rule group

On Thu, May 19, 2011 at 08:33:10PM +0200, Jens Axboe wrote:
> On 2011-05-18 21:13, Vivek Goyal wrote:
> > Hi,
> > 
> > Block throttling code takes request queue lock for every incoming bio
> > (blk_throtl_bio()). This is true even if there are no throttle rules in
> > the group. This is a common case for root cgroup where distributions
> > will have throttling support compiled in but a vast majority of users
> > will not be specifying throttling rule.
> > 
> > This patch series tries to make bio processing lockless (no requeust
> > queue lock), if there are no rules specified for the group. Once
> > a bio is submitted, under rcu_read_lock() we search for the group, 
> > update the stats and release the rcu lock. request queue lock is taken
> > only if there are throttling rules specified in the group.
> > 
> > I have made some of the dispatch stats per cpu so that these can be updated
> > without taking request queue lock.
> > 
> > On my system for a simple dd as follows, request queue lock acquisition
> > count has gone down by 11% roughly.
> > 
> > dd if=/mnt/zerofile-1G of=/dev/null bs=4K iflag=direct
> > 
> > lockstat output vanilla kernel
> > -----------------------------
> > class name			acquisitions	holdtime-total
> > 
> > &(&q->__queue_lock)->rlock:	2360944		1850183.07
> > 
> > lockstat output with patched kernel
> > -----------------------------------
> > class name			acquisitions	holdtime-total
> > &(&q->__queue_lock)->rlock:	2098599		1430478.79
> > 
> > 
> > I did test on a 4 cpu system doing IO to one SSD. I did not see any
> > significant improvement in throughput. I suspect that I never saturated
> > the cpus hence I don't see the improvement in throughput. I will see
> > if I can get more testing done on this and see if I notice IO throughput
> > improvement.
> > 
> > Jens, first patch of the series is already in your for-linus branch. I
> > was waiting for it to be pushed to Linus and then I can drop that first
> > patch.
> 
> Vivek, I get weird things in these patches. In fact I always get on your
> patches. = are =3D, =20 some places, and line breaks. Can I ask you to
> try and resend it to axboe@...nel.dk just to see if it's the company MTA
> screwing things up, or if it's something at your end?

Sure, I am resending the series to your axboe@...nel.dk id. If you still
see the problem there, then I need to look into my setup.

I had cced the patches to myself. So took the mailbox of  the series
and did "git am <patch-series>" and it gave two warnings about space
before tab indent.

/home/vgoyal/main/git/linux-2.6/.git/rebase-apply/patch:16: space before
tab in indent.
 	struct backing_dev_info *bdi = &td->queue->backing_dev_info;
/home/vgoyal/main/git/linux-2.6/.git/rebase-apply/patch:17: space before
tab in indent.
 	unsigned int major, minor;
warning: 2 lines add whitespace errors.

Apart from that nothing else appeared. I will fix above two warnings and
resend the series and this time on your axboe@...nel.dk id.

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/