From: Andi Kleen <ak@suse.de>
To: Erich Focht <efocht@hpce.nec.com>
Cc: Andi Kleen <ak@suse.de>, LSE <lse-tech@lists.sourceforge.net>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [Lse-tech] Node affine NUMA scheduler extension
Date: Tue, 27 May 2003 12:01:48 +0200 [thread overview]
Message-ID: <20030527100148.GE31510@wotan.suse.de> (raw)
In-Reply-To: <200305271154.52608.efocht@hpce.nec.com>
On Tue, May 27, 2003 at 11:54:52AM +0200, Erich Focht wrote:
> > But the main problems I have is that the tuning for threads is very
> > difficult. On AMD64 where Node equals CPU it is important
> > to home node balance threads too. After some experiments I settled on
> > homenode assignment on the first load balance (called "lazy homenode")
> > When a thread clones it initially executes on the CPU of the parent, but
> > there is a window until the first load balance tick where it can allocate
> > memory on the wrong node. I found a lot of code runs very badly until the
> > cache decay parameter is set to 0 (no special cache affinity) to allow
> > quick initial migration.
>
> Interesting observation, I didn't make it when I tried the lazy
> homenode (quite a while ago). But I was focusing on MPI jobs. So what
> if we add a condition to CAN_MIGRATE which disables the cache affinity
> before the first load balance?
What I currently have is two cache decay variables: one is used if the
homenode is not assigned, the other otherwise. Both are sysctls too.
But it obviously only works with lazy homenode, but the state is the same.
I'm still not completely happy with it though.
Why exactly did you gave up to use the lazy homenode?
>
> > Migration directly on fork/clone requires a lot
> > of changes and also breaks down on some benchmarks.
>
> Hmmm, I wouldn't allow this to any task/child, only to special
> ones. Under 2.4 I currently use a sched_balance_fork() function
Yes, I agree.
> similar to sched_balance_exec(). Tasks have a default initial load
> balancing policy of being migrated (and selecting the homenode) at
> exec(). This can be changed (with prctl) to fork(). The ilb policy is
> inheritable. Works fine for OpenMP jobs.
Hmm, I should try that I guess. Where do you call it? At the end of do_fork?
I tried to hack up wake_up_forked_process() to do it, but it required
large scale changes all over the scheduler so I eventually gave up.
-Andi
next prev parent reply other threads:[~2003-05-27 9:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-27 8:31 Erich Focht
2003-05-27 9:11 ` [Lse-tech] " Andi Kleen
2003-05-27 9:54 ` Erich Focht
2003-05-27 10:01 ` Andi Kleen [this message]
2003-05-27 11:39 ` Erich Focht
2003-05-27 11:40 ` Andi Kleen
2003-05-27 11:50 ` Erich Focht
2003-05-27 15:38 ` Martin J. Bligh
2003-05-27 21:28 ` Erich Focht
2003-05-27 21:51 ` Martin J. Bligh
2003-05-28 17:02 ` Erich Focht
2003-05-28 17:13 ` Martin J. Bligh
2003-05-28 18:14 ` Rick Lindsley
2003-05-28 19:32 ` Martin J. Bligh
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=20030527100148.GE31510@wotan.suse.de \
--to=ak@suse.de \
--cc=efocht@hpce.nec.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
/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
all inboxes | Powered by JetHome®