LKML Archive on
help / color / mirror / Atom feed
From: Vaidyanathan Srinivasan <>
To: Ranjit Manomohan <>
Cc:, Mike Galbraith <>,
	Nikhil Rao <>, Salman Qazi <>,
	Dhaval Giani <>,
	Peter Zijlstra <>,
	Ingo Molnar <>,
	Thomas Gleixner <>,
	Venkatesh Pallipadi <>,
	Paul Turner <>
Subject: Re: [ANNOUNCE] Linsched for 2.6.35 released
Date: Tue, 8 Feb 2011 23:40:26 +0530	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

* Ranjit Manomohan <> [2010-11-15 17:52:05]:

> On Mon, Oct 18, 2010 at 9:52 PM, Vaidyanathan Srinivasan
> <> wrote:
> > * Ranjit Manomohan <> [2010-10-12 10:29:54]:
> >


> > 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?


  reply	other threads:[~2011-02-08 18:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-12 17:29 Ranjit Manomohan
2010-10-19  4:52 ` Vaidyanathan Srinivasan
2010-11-16  1:52   ` Ranjit Manomohan
2011-02-08 18:10     ` Vaidyanathan Srinivasan [this message]
2011-02-15 18:25       ` Ranjit Manomohan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [ANNOUNCE] Linsched for 2.6.35 released' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).