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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 19 May 2011 20:33:10 +0200
From:	Jens Axboe <jaxboe@...ionio.com>
To:	Vivek Goyal <vgoyal@...hat.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 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?

-- 
Jens Axboe

--
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/