linux-kernel - Re: [PATCH V3] block/throttle: Add IO throttled information in blkio.throttle

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]

Date:	Fri, 19 Oct 2012 15:39:32 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Robin Dong <robin.k.dong@...il.com>, linux-kernel@...r.kernel.org,
	Robin Dong <sanbai@...bao.com>, Jens Axboe <axboe@...nel.dk>,
	Tao Ma <boyu.mt@...bao.com>
Subject: Re: [PATCH V3] block/throttle: Add IO throttled information in
 blkio.throttle

On Fri, Oct 19, 2012 at 12:36:00PM -0700, Tejun Heo wrote:
> Hello, Vivek.
> 
> On Fri, Oct 19, 2012 at 11:00:11AM -0400, Vivek Goyal wrote:
> > > That way we can stick to the usual stats facility.
> > 
> > So how does this help? Because it is a monotonically increasing value
> > we can use per cpu stats without extra locking? Or somthing else?
> 
> It's generally much simpler to expose dumb increasing counters.  You
> don't have to worry about mismatching decrements (for whatever reason,
> percpu or segmented counters), so unless there's a pretty good reason
> to deviate, why deviate?

I really can't think of a reason to deviate. I was just curious of
advantages. I think it does make sense to not get into decrement business
and let user space subtract two values and figure out how much IO from
the group is throttled.

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/