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:	Wed, 15 Jul 2015 12:29:52 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	axboe@...nel.dk, linux-kernel@...r.kernel.org, kernel-team@...com,
	avanzini.arianna@...il.com
Subject: Re: [PATCH 09/10] blkcg: move io_service_bytes and io_serviced stats
 into blkcg_gq

On Wed, Jul 15, 2015 at 12:04:25PM -0400, Tejun Heo wrote:
> Hello, Vivek.
> 
> On Tue, Jul 14, 2015 at 12:09:08PM -0400, Vivek Goyal wrote:
> > So now blkio.io_serviced will switch to accounting number of bios
> > instead of number of requests? I feel given other stats, things
> > are still confusing as other stats will similar name give stats
> > about requests and not bios.
> > 
> > IMHO, for a policy, either all the stats should be in bio or in terms
> > of requests. Having a mix of these is even more confusing.
> 
> Well, the actual problem is that we have so many stats which are
> hardly useful except for debugging blkcg itself.  Most of these stats
> aren't meaningful to userland.
> 
> > For example, IIUC, now blkio.io_serviced will keep count in terms of
> > bios while blkio.io_queued will keep count in terms of number of
> > requests.
> 
> Why does that matter tho?  io_queued tracks the number of requests
> currently queued.  It's not an accumulative stat.  It isn't possible
> to meaningfully correlate that stat with anything else there.
> 
> > If we are keeping common stats at block layer (instead of per policy),
> > I am wondering if it will make sense to reflect that in new cgroup
> > files which are common to all policies in that cgroup, instead of being per
> > policy. And deperecate respective per policy stat files over a period of time.
> 
> So, that's the plan for unified hierarchy and this is the groundwork
> for that.  There's no point in disturbing interface for the
> traditional hierarchies at this point.  We can simply add the new
> stats and use the new ones only on the unified hierarchy but frankly
> how many identical stats should we keep?  What we're doing is already
> pretty silly and I don't really want to add more on top.

Hi Tejun,

Ok. I am personally little apprehensive of changing the meaning of 
current stat, but I can live with it.

Can you please also update the blkio-controller.txt to reflect these
changes. I think following sections would require updation.

blkio.throttle.io_serviced
blkio.throttle.io_service_bytes

And we could mention in blkio.io_serviced that accounting is terms of
numeber of bios.

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/

Powered by blists - more mailing lists