public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthew Dobson <colpatch@us.ibm.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>,
	"Martin J. Bligh" <mbligh@aracnet.com>, Andi Kleen <ak@suse.de>
Subject: Re: [RFC PATCH] sched_domains: Make SD_NODE_INIT per-arch
Date: Thu, 30 Sep 2004 11:36:52 -0700	[thread overview]
Message-ID: <1096569412.20097.13.camel@arrakis> (raw)
In-Reply-To: <415BC0BC.6040902@yahoo.com.au>

On Thu, 2004-09-30 at 01:15, Nick Piggin wrote:
> Matthew Dobson wrote:
> > IA64 already has their own version of SD_NODE_INIT, tuned for their
> > extremely large machines.  I think that all arches would benefit from
> > having their own, arch-specific SD_NODE_INIT initializer, rather than
> > the one-size-fits-all variant we've got now.
> > 
> 
> I suppose the patch is pretty good (IIRC Martin liked the idea).
> I guess it will at least increase the incidence of copy+paste,
> if not getting people to think harder ;)

Thanks!  Martin does like the idea, and I think Andi Kleen likes the
idea of being able to tune sched_domains for x86_64, too.  Any comments,
Andi?

The patch is pretty simple.  I don't think it will increase any
copy+pasting because I don't believe anyone has modified SD_NODE_INIT at
all since it's been implemented, and certainly not for many kernel
releases.  I think part of the reason for that is that it is currently
impossible to tweak the values for your architecture of choice because
modifying the values now will change EVERYONE's sched_domains timings. 
Which is bad. :(  If anyone wants to tweak SD_NODE_INIT, they shouldn't
be copying+pasting those values to all architectures.  Besides, IA64
already gets their own SD_NODE_INIT to play with, why shouldn't everyone
else! ;)


> Can I be lame and ask that you keep this around until closer
> to 2.6.10? I have a few possible scheduler performance
> improvments that I'd like to get tested in -mm after 2.6.9
> and this would make things a bit harder :P
> 
> I don't think anyone is looking at getting any tweaks in before
> then...

I would like to try to get this in before then, unless this will really
make things difficult for you.  2.6.9 is looking to be a pickup point
for distros, so getting this patch in now (pre 2.6.9) means that distros
can add tiny patches to their builds to simply tweak individual
architecture values without having to diverge from mainline by
implementing this patch on their own.  It also means that any tuning
work that the distros do can easily be pushed back to mainline by
simpling sending a patch per architecture with new values.  It makes
those patches safe and minimizes conflicts.

Will this patch really make your scheduler improvements that much harder
to test/implement?  I don't think it should, unless your improvements
are tweaking the values in SD_NODE_INIT, since that is all this
touches...  Even after this patch, SD_NODE_INIT is still picked up in
include/linux/sched.h, so the changes required to cope with this patch
should be minimal...

-Matt


  reply	other threads:[~2004-09-30 18:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-29  1:12 [RFC PATCH] sched_domains: Make SD_NODE_INIT per-arch Matthew Dobson
2004-09-30  8:15 ` Nick Piggin
2004-09-30 18:36   ` Matthew Dobson [this message]
2004-09-30 19:23     ` Andrew Morton
2004-09-30 20:20       ` Matthew Dobson
2004-10-01  6:15       ` Martin J. Bligh
2004-10-01 22:20         ` Matthew Dobson
2004-10-02 16:02           ` Martin J. Bligh
2004-09-30 20:45     ` Andi Kleen
2004-09-30 21:06       ` Matthew Dobson
2004-09-30 21:12         ` Andi Kleen
2004-09-30 23:47           ` Matthew Dobson

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=1096569412.20097.13.camel@arrakis \
    --to=colpatch@us.ibm.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@aracnet.com \
    --cc=nickpiggin@yahoo.com.au \
    /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