From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757647Ab2CHPpb (ORCPT ); Thu, 8 Mar 2012 10:45:31 -0500 Received: from mail-we0-f174.google.com ([74.125.82.174]:49765 "EHLO mail-we0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753839Ab2CHPp2 (ORCPT ); Thu, 8 Mar 2012 10:45:28 -0500 Date: Thu, 8 Mar 2012 16:45:21 +0100 From: Frederic Weisbecker To: Pantelis Antoniou Cc: linux-kernel@vger.kernel.org, linaro-kernel@lists.linaro.org, linaro-dev@lists.linaro.org, Steven Goss , Kevin Hilman , Matt Porter , Kumar Gala , Robin Randhawa , Amit Kucheria , charles.garcia-tobin@arm.com, Morten Rasmussen , chris.redpath@arm.com, Paul Turner , Peter Zijlstra , dmitry.antipov@linaro.org, Stephane Sintes , Ingo Molnar Subject: Re: [RFC] Scheduler recorder and playback Message-ID: <20120308154519.GE7976@somewhere.redhat.com> References: <85A3EFC3-FAE0-4B3A-AAA0-85FA435A9F7B@antoniou-consulting.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <85A3EFC3-FAE0-4B3A-AAA0-85FA435A9F7B@antoniou-consulting.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/