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

[Jens Axboe]

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@xxxxxxxxx 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/