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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
