On Mon, Oct 18, 2010 at 9:52 PM, Vaidyanathan Srinivasan
<[email protected]> wrote:
> * Ranjit Manomohan <[email protected]> [2010-10-12 10:29:54]:
>
>> Hi,
>> ? I would like to announce the availability of the Linux Scheduler Simulator
>> (Linsched) for 2.6.35.
>>
>> Originally developed at the University of North Carolina, LinSched is a
>> user-space program that hosts the Linux scheduling subsystem.
>> Its purpose is to provide a tool for observing and modifying the behavior
>> of the Linux scheduler. This makes it a valuable tool in prototyping new
>> Linux scheduling policies in a way that may be easier (or otherwise
>> less painful or time-consuming) to many developers when compared
>> to working with real hardware.
>
> The idea and framework looks very interesting. ?I tried it out in
> order to understand the workload model and verification model and it
> worked fine for the test cases that you have provided.
Thanks for evaluating it.
>
>> Since Linsched allows arbitrary hardware topologies to be modeled,
>> it enables testing of scheduler changes on hardware that may not be
>> easily accessible to the developer. For example, most developers don't
>> have access to a quad-core quad-socket box, but they can use LinSched
>> to see how their changes affect the scheduler on such boxes.
>
> I am interested in trying this simulator in order to
> design/study/verify task placement logic within the SMP loadbalancer.
> Basically the effects of SD_POWERSAVINGS_BALANCE, SD_PREFER_SIBLING,
> etc in various topologies.
>
> The current interface and verification mechanism is to create tasks
> and observe the runtime received by each task. ?In an ideal
> loadbalancer situation, all tasks should have received runtime
> proportional to their priority.
>
> Can you help me figure out how to get to kstat_cpu() or per-cpu
> kernel_stat accounting/utilisation metrics within the simulation?
we don't use the kstat_cpu accounting in the simulation since it does
not really make sense in this environment.
We have a timer driven loop that advances time globally and kicks of
events scheduled to run at specified times on each CPU. The periodic
timer tick is one among these events. Since there is really no notion
of system vs user time in this scenario, the current code disables the
update_process_times routine. I am not sure how these times relate to
the task placement logic you are trying to verify. If you could let me
know how you plan to use these then I can try to accommodate that in
the simulation.
Sorry for the delay in response. My mail filters messed this up.
-Thanks,
Ranjit
>
> Thanks for sharing the framework.
>
> --Vaidy
>
>
* Ranjit Manomohan <[email protected]> [2010-11-15 17:52:05]:
> On Mon, Oct 18, 2010 at 9:52 PM, Vaidyanathan Srinivasan
> <[email protected]> wrote:
> > * Ranjit Manomohan <[email protected]> [2010-10-12 10:29:54]:
> >
[snip]
> > Can you help me figure out how to get to kstat_cpu() or per-cpu
> > kernel_stat accounting/utilisation metrics within the simulation?
>
> we don't use the kstat_cpu accounting in the simulation since it does
> not really make sense in this environment.
>
> We have a timer driven loop that advances time globally and kicks of
> events scheduled to run at specified times on each CPU. The periodic
> timer tick is one among these events. Since there is really no notion
> of system vs user time in this scenario, the current code disables the
> update_process_times routine. I am not sure how these times relate to
> the task placement logic you are trying to verify. If you could let me
> know how you plan to use these then I can try to accommodate that in
> the simulation.
The current setup lets us find how much time each task was run.
I would like to use the kernel_stat information to understand 'which
cpu' ran the task. Basically we could place nr_tasks < nr_cpus and
see them settle to the right CPUs within the sched domain topology.
This can be verified by checking the CPU's utilisation or run time at
the end of the simulation. Like two tasks on the same socket of
a dual-socket dual-core system should settle to one task per socket.
The load balancer should be able to spread the tasks around slowly.
The ability to create diverse topology within linsched is very
useful to test these load balancer functions and corner cases.
> Sorry for the delay in response. My mail filters messed this up.
I got your reply earlier. No problem with the delay.
Do you have a new version to share? Any new feature that you are planning?
--Vaidy
On Tue, Feb 8, 2011 at 10:10 AM, Vaidyanathan Srinivasan
<[email protected]> wrote:
> * Ranjit Manomohan <[email protected]> [2010-11-15 17:52:05]:
>
>> On Mon, Oct 18, 2010 at 9:52 PM, Vaidyanathan Srinivasan
>> <[email protected]> wrote:
>> > * Ranjit Manomohan <[email protected]> [2010-10-12 10:29:54]:
>> >
>
> [snip]
>
>> > Can you help me figure out how to get to kstat_cpu() or per-cpu
>> > kernel_stat accounting/utilisation metrics within the simulation?
>>
>> we don't use the kstat_cpu accounting in the simulation since it does
>> not really make sense in this environment.
>>
>> We have a timer driven loop that advances time globally and kicks of
>> events scheduled to run at specified times on each CPU. The periodic
>> timer tick is one among these events. Since there is really no notion
>> of system vs user time in this scenario, the current code disables the
>> update_process_times routine. I am not sure how these times relate to
>> the task placement logic you are trying to verify. If you could let me
>> know how you plan to use these then I can try to accommodate that in
>> the simulation.
>
> The current setup lets us find how much time each task was run.
> I would like to use the kernel_stat information to understand 'which
> cpu' ran the task. ?Basically we could place nr_tasks < nr_cpus and
> see them settle to the right CPUs within the sched domain topology.
> This can be verified by checking the CPU's utilisation or run time at
> the end of the simulation. ?Like two tasks on the same socket of
> a dual-socket dual-core system should settle to one task per socket.
> The load balancer should be able to spread the tasks around slowly.
>
> The ability to create diverse topology within linsched is very
> useful to test these load balancer functions and corner cases.
Ok, I understand what you are looking for. There does not seem to be
anything in the kernel that I can reuse. I can add a Linsched specific
per cpu task counter to get the stats. I will try to send out an
update in a couple of days.
>
>> Sorry for the delay in response. My mail filters messed this up.
>
> I got your reply earlier. No problem with the delay.
> Do you have a new version to share? ?Any new feature that you are planning?
Unfortunately we have fallen a little behind in terms of keeping
linsched up to date with mainline kernel releases. Hopefully we can
get an updated version out this summer. Our current plans are to
include a record/replay type of option to the simulation that will
allow us to optimize a particular workload. Please let me know if
there is anything else that you would like to see added.
-Thanks,
Ranjit
>
> --Vaidy
>
>