linux-kernel - Re: [RFD PATCH 10/10] sched: io

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]

Message-ID: <alpine.LFD.2.11.1410301059180.20099@knanqh.ubzr>
Date:	Thu, 30 Oct 2014 11:07:54 -0400 (EDT)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Daniel Lezcano <daniel.lezcano@...aro.org>,
	linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
	axboe@...nel.dk, rafael.j.wysocki@...el.com, mingo@...nel.org,
	preeti@...ux.vnet.ibm.com, Morten.Rasmussen@....com,
	mturquette@...aro.org, tuukka.tikkanen@...aro.org,
	patches@...aro.org
Subject: Re: [RFD PATCH 10/10] sched: io_latency: Tracking via buckets

On Thu, 30 Oct 2014, Peter Zijlstra wrote:

> On Wed, Oct 22, 2014 at 03:57:53PM +0200, Daniel Lezcano wrote:
> > The size of the bucket is the bucket interval and represent the resolution
> > of the statistic model. Eg with a bucket interval of 1us, it leads us to
> > do statitics on all numbers, with of course a bad prediction because the
> > number of latencies is big. A big interval can give better statistics,
> > but can give us a misprediction as the interval is larger.
> > 
> > Choosing the size of the bucket interval vs the idle sleep time is the
> > tradeoff to find. With a 200us bucket interval, the measurements show
> > we still have good predictions, less mispredictions and cover the idle
> > state target residency.
> > 
> 
> For the record:
> 
> The suggestion in DUS was to align the bucket sizes with the various
> break even times of the actual C states.
> 
> I forgot who suggested this; it might have been Morten; but it seems to
> make sense.

I suggested that a while ago too.  But IIRC Daniel envisioned some 
possible additional use for those buckets in the future e.g.. a measure 
of how many tasks can be packed on a CPU knowing their sleep periods.

However, if the IO latency can be predicted at the driver level with 
good accuracy (it normally should) then there is no need to do any kind 
of averaging and bucketing since the driver should be able to provide a 
relatively precise number almost every time.


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