From: Andrea Arcangeli <andrea@suse.de>
To: Ingo Molnar <mingo@elte.hu>
Cc: "David Lang" <david.lang@digitalinsight.com>,
"Dieter Nützel" <Dieter.Nuetzel@hamburg.de>,
"Linux Kernel List" <linux-kernel@vger.kernel.org>
Subject: Re: [announce] [patch] ultra-scalable O(1) SMP and UP scheduler
Date: Fri, 4 Jan 2002 15:45:00 +0100 [thread overview]
Message-ID: <20020104154500.N1561@athlon.random> (raw)
In-Reply-To: <20020104143659.I1561@athlon.random> <Pine.LNX.4.33.0201041641320.7409-100000@localhost.localdomain>
In-Reply-To: <Pine.LNX.4.33.0201041641320.7409-100000@localhost.localdomain>; from mingo@elte.hu on Fri, Jan 04, 2002 at 04:44:32PM +0100
On Fri, Jan 04, 2002 at 04:44:32PM +0100, Ingo Molnar wrote:
>
> On Fri, 4 Jan 2002, Andrea Arcangeli wrote:
>
> > + {
> > + int counter = current->counter;
> > + p->counter = (counter + 1) >> 1;
> > + current->counter = counter >> 1;
> > + p->policy &= ~SCHED_YIELD;
> > + current->policy |= SCHED_YIELD;
> > current->need_resched = 1;
> > + }
>
> yep - good, this means that applications got some fair testing already.
yes :).
> What i mentioned in the previous email is that on SMP this solution is
> still not the optimal one under the current scheduler, because the wakeup
> of the child process might end up pushing the process to another (idle)
> CPU - worsening the COW effect with SMP-interlocking effects. This is why
> i introduced wake_up_forked_process() that knows about this distinction
> and keeps the child on the current CPU.
The right thing to do is not obvious here. If you keep the parent on the
current CPU, it will be the parent that will be rescheduled on another
(idle) cpu. But then the parent could be the "real" app, or something
that would better not migrate over and over to all cpus (better to run
the child in another cpu in such case). Of course we cannot avoid child
and parent to run in parallel if there are idle cpus or we risk to waste
a whole timeslice worth of cpu cycles. But, at the very least we should
avoid to set need_resched to 1 in the parent if the child is getting
migrated, so at least that bit can be optimized away with an aware
wake_up_forked_process.
Andrea
next prev parent reply other threads:[~2002-01-04 14:47 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-04 7:42 [announce] [patch] ultra-scalable O(1) SMP and UP scheduler Dieter Nützel
2002-01-04 8:02 ` David Lang
2002-01-04 11:44 ` Ingo Molnar
2002-01-04 11:33 ` David Lang
2002-01-04 13:39 ` Andrea Arcangeli
2002-01-04 14:04 ` Ingo Molnar
2002-01-04 13:36 ` Andrea Arcangeli
2002-01-04 15:44 ` Ingo Molnar
2002-01-04 14:45 ` Andrea Arcangeli [this message]
[not found] <20020107.191742.730580837.rene.rebe@gmx.net>
[not found] ` <Pine.LNX.4.33.0201072124380.14212-100000@localhost.localdomain>
2002-01-07 19:53 ` Rene Rebe
-- strict thread matches above, loose matches on Subject: below --
2002-01-07 17:34 Rene Rebe
[not found] <20020104074239.94E016DAA6@mail.elte.hu>
2002-01-04 11:42 ` Ingo Molnar
2002-01-05 0:28 ` Roger Larsson
2002-01-05 7:53 ` george anzinger
2002-01-05 16:54 ` Robert Love
2002-01-05 12:42 ` Ingo Molnar
2002-01-04 11:16 rwhron
2002-01-04 13:20 ` Ingo Molnar
2002-01-04 3:56 Ed Tomlinson
2002-01-04 2:19 Ingo Molnar
2002-01-04 4:27 ` Oliver Xymoron
2002-01-04 5:34 ` Ian Morgan
2002-01-04 10:30 ` Anton Blanchard
2002-01-04 12:53 ` Ingo Molnar
2002-01-04 14:18 ` Thomas Cataldo
2002-01-04 14:46 ` dan kelley
2002-01-04 17:07 ` Ingo Molnar
2002-01-04 15:22 ` Nikita Danilov
2002-01-05 4:33 ` Davide Libenzi
2002-01-05 20:24 ` Ingo Molnar
2002-01-05 19:49 ` Mika Liljeberg
2002-01-05 22:00 ` Ingo Molnar
2002-01-05 21:04 ` Mika Liljeberg
2002-01-05 23:04 ` Davide Libenzi
2002-01-05 23:41 ` Alan Cox
2002-01-05 23:46 ` Davide Libenzi
2002-01-06 0:47 ` Linus Torvalds
2002-01-06 2:57 ` Ingo Molnar
2002-01-06 1:27 ` Linus Torvalds
2002-01-06 1:45 ` Davide Libenzi
2002-01-06 3:55 ` Ingo Molnar
2002-01-06 2:16 ` Davide Libenzi
2002-01-06 3:41 ` Ingo Molnar
2002-01-06 2:02 ` Davide Libenzi
2002-01-06 2:13 ` Alan Cox
2002-01-06 2:12 ` Davide Libenzi
2002-01-06 2:20 ` Alan Cox
2002-01-06 2:17 ` Davide Libenzi
2002-01-06 4:07 ` Ingo Molnar
2002-01-06 2:23 ` Davide Libenzi
2002-01-06 2:30 ` Alan Cox
2002-01-06 4:19 ` Ingo Molnar
2002-01-07 3:08 ` Richard Henderson
2002-01-07 3:16 ` Linus Torvalds
2002-01-07 3:31 ` Davide Libenzi
2002-01-07 3:34 ` Linus Torvalds
2002-01-07 3:49 ` Davide Libenzi
2002-01-06 4:01 ` Ingo Molnar
2002-01-06 4:08 ` Ingo Molnar
2002-01-06 4:16 ` Ingo Molnar
2002-01-06 3:55 ` Luc Van Oostenryck
2002-01-07 8:00 ` Jens Axboe
2002-01-06 2:49 ` Ingo Molnar
2002-01-07 2:58 ` Rusty Russell
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=20020104154500.N1561@athlon.random \
--to=andrea@suse.de \
--cc=Dieter.Nuetzel@hamburg.de \
--cc=david.lang@digitalinsight.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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