[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120308154519.GE7976@somewhere.redhat.com>
Date: Thu, 8 Mar 2012 16:45:21 +0100
From: Frederic Weisbecker <fweisbec@...il.com>
To: Pantelis Antoniou <panto@...oniou-consulting.com>
Cc: linux-kernel@...r.kernel.org, linaro-kernel@...ts.linaro.org,
linaro-dev@...ts.linaro.org, Steven Goss <steve.goss@...com>,
Kevin Hilman <khilman@...com>, Matt Porter <mporter@...com>,
Kumar Gala <galak@...com>,
Robin Randhawa <robin.randhawa@....com>,
Amit Kucheria <amit.kucheria@...aro.org>,
charles.garcia-tobin@....com,
Morten Rasmussen <morten.rasmussen@....com>,
chris.redpath@....com, Paul Turner <pjt@...gle.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
dmitry.antipov@...aro.org, Stephane Sintes <s-sintes@...com>,
Ingo Molnar <mingo@...e.hu>
Subject: Re: [RFC] Scheduler recorder and playback
On Thu, Mar 08, 2012 at 03:20:53PM +0200, Pantelis Antoniou wrote:
> Hi there,
>
> There's considerable activity in the subject of the scheduler lately and how to
> adapt it to the peculiarities of the new class of hardware coming out lately,
> like the big.LITTLE class of devices from a number of manufacturers.
>
> The platforms that Linux runs are very diverse, and run differing workloads.
> For example most consumer devices will very likely run something like Android,
> with common use cases such as audio and/or video playback. Methods to achieve
> lower power consumption using a power aware scheduler are under investigation.
>
> Similarly for server applications, or VM hosting, the behavior of the scheduler
> shouldn't have adverse performance implications; any power saving on top of that
> would be a welcome improvement.
>
> The current issue is that scheduler development is not easily shared between
> developers. Each developer has their own 'itch', be it Android use cases, server
> workloads, VM, etc. The risk is high of optimizing for one's own use case and
> causing severe degradation on most other use cases.
>
> One way to fix this problem would be the development of a method with which one
> could perform a given use-case workload in a host, record the activity in a
> interchangeable portable trace format file, and then play it back on another
> host via a playback application that will generate an approximately similar load
> which was observed during recording.
>
> The way that the two hosts respond under the same load generated by the playback
> application can be compared, so that the performance of the two scheduler implementations
> measured in various metrics (like performance, power consumption etc.) can be
> evaluated.
>
> The fidelity of the this approximation is of great importance but it is debatable
> if it is possible to have a fully identical load generated, since details of the hosts
> might differ in such a way that such a thing is impossible.
> I believe that it should be possible at least to simulate a purely CPU load, and the
> blocking behavior of tasks, in such a way that it would result in scheduler decisions
> that can be compared and shared among developers.
>
> The recording part I believe can be handled by the kernel's tracing infrastructure,
> either by using the existing tracepoints, or need be adding more; possibly even
> creating a new tracer solely for this purpose.
> Since some applications can adapt their behavior according to insufficient system
> resources (think media players that can drop frames for example), I think it would
> be beneficial to record such events to the same trace file.
>
> The trace file should have a portable format so that it can be freely shared between
> developers. An ASCII format like we currently use should be OK, as long as it
> doesn't cause too much of an effect during execution of the recording.
>
> The playback application can be implemented via two ways.
>
> One way, which is the LinSched way would be to have the full scheduler implementation
> compiled as part of said application, and use application specific methods to evaluate
> performance. While this will work, it won't allow comparison of the two hosts in a meaningful
> manner.
>
> For both scheduler and platform evaluation, the playback application will generate the load
> on the running host by simulating the source host's recorded work load session.
> That means emulating process activity like forks, thread spawning, blocking on resources
> etc. It is not clear to me yet if that's possible without using some kind of kernel
> level helper module, but not requiring such is desirable.
>
> Since one would have the full trace of scheduling activity: past, present and future; there would
> be the possibility of generating a perfect schedule (as defined by best performance, or best
> power consumption), and use it as a yardstick of evaluation against the actual scheduler.
> Comparing the results, you would get an estimate of the best case improvement that could be
> achieved if the ideal scheduler existed.
>
> I know this is a bit long, but I hope this can be a basis of thinking on how to go about
> developing this.
>
> Regards
>
> -- Pantelis
>
Hi,
May be you could have a look at the perf sched tool.
It has a replay feature. I think it perform well basic replay but it can
certainly be enhanced.
>
>
>
> --
> 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/
--
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