public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	"Siddha, Suresh B" <suresh.b.siddha@intel.com>
Subject: Re: [patch 5/5] sched: consolidate sbe sbf
Date: Wed, 6 Apr 2005 08:27:23 +0200	[thread overview]
Message-ID: <20050406062723.GC5973@elte.hu> (raw)
In-Reply-To: <42532427.3030100@yahoo.com.au>


* Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> 5/5
> 
> Any ideas about what to do with schedstats?
> Do we really need balance on exec and fork as seperate
> statistics?

> Consolidate balance-on-exec with balance-on-fork. This is made easy
> by the sched-domains RCU patches.
> 
> As well as the general goodness of code reduction, this allows
> the runqueues to be unlocked during balance-on-fork.
> 
> schedstats is a problem. Maybe just have balance-on-event instead
> of distinguishing fork and exec?
> 
> Signed-off-by: Nick Piggin <nickpiggin@yahoo.com.au>

looks good.

 Acked-by: Ingo Molnar <mingo@elte.hu>

while the code is now consolidated, i think we still need the separate 
fork/exec stats for schedstat. We have 3 conceptual ways to start off a 
new context: fork(), pthread_create() and execve(), and applications use 
them in different patterns. We have different flags and tuning 
parameters for two of them (which might have to become 3, i'm not 
entirely convinced we'll be able to ignore the 'process vs. thread' 
condition in wake_up_new_task(), STREAM is a really bad example in that 
sense), so we need 2 (or 3) separate stats.

	Ingo

  reply	other threads:[~2005-04-06  6:27 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-05 23:44 [patch 1/5] sched: remove degenerate domains Nick Piggin
2005-04-05 23:45 ` [patch 2/5] sched: NULL domains Nick Piggin
2005-04-05 23:46   ` [patch 3/5] sched: multilevel sbe and sbf Nick Piggin
2005-04-05 23:47     ` [patch 4/5] sched: RCU sched domains Nick Piggin
2005-04-05 23:49       ` [patch 5/5] sched: consolidate sbe sbf Nick Piggin
2005-04-06  6:27         ` Ingo Molnar [this message]
2005-04-06  8:09           ` Nick Piggin
2005-04-06  8:16             ` Nick Piggin
2005-04-07  7:17               ` Ingo Molnar
2005-04-07  7:15             ` Ingo Molnar
2005-04-06  6:18       ` [patch 4/5] sched: RCU sched domains Ingo Molnar
2005-04-06  8:01         ` Nick Piggin
2005-04-07  7:11           ` Ingo Molnar
2005-04-07  7:58             ` Nick Piggin
2005-04-11 22:15               ` Paul E. McKenney
2005-04-12  0:03                 ` Nick Piggin
2005-04-06  5:54     ` [patch 3/5] sched: multilevel sbe and sbf Ingo Molnar
2005-04-06  7:53       ` Nick Piggin
2005-04-06  5:45   ` [patch 2/5] sched: NULL domains Ingo Molnar
2005-04-06  5:48     ` Ingo Molnar
2005-04-06  7:51       ` Nick Piggin
2005-04-06  5:44 ` [patch 1/5] sched: remove degenerate domains Ingo Molnar
2005-04-06  7:10   ` Siddha, Suresh B
2005-04-06  7:13     ` Ingo Molnar
2005-04-06  8:12       ` Nick Piggin
2005-04-06  7:49   ` Nick Piggin
2005-04-07  7:00     ` Ingo Molnar

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20050406062723.GC5973@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=suresh.b.siddha@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox