[lkml]   [2012]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Scheduler recorder and playback
On Thu, Mar 8, 2012 at 6:50 PM, 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.
I believe many people would have had this simple idea, but I don't know why,
or if, it's bad. So I am going to ask.

Why not have much coarser, but deterministic, load patterns using user
space apps
(perhaps modified to log important characteristics of execution) ?

We could have, say, three sets of stress patterns one each for Server, Desktop
and Mobile. Only deterministic would be top-level usage pattern (say by having
some app-spawning script running from init, with least or none
external influence)

Say the 'Mobile-profile' script could spawn multimedia playback,
3d game playback, storage access and suspend/resume cycles in some parallel
and serial manner. Each task at the end tells how it was treated
during its lifetime
(total dropped frames, average latency, overall power consumed etc). From which
we calculate a 'GPA'.
For any modification in the scheduler, we could see how it affects the
current score
for each profile running on respective reference platforms.

Kind Regards

ps: I had to drop Amit Kucheria <<amit.kucheria@li>, otherwise my post
wouldn't fire.

Jo darr gaya, so marr gaya!

 \ /
  Last update: 2012-03-08 18:43    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean