From: "J . A . Magallon" <jamagallon@able.es>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: 2.4.4 sluggish under fork load
Date: Tue, 1 May 2001 19:33:29 +0200 [thread overview]
Message-ID: <20010501193329.C1246@werewolf.able.es> (raw)
In-Reply-To: <20010430195149.F19620@athlon.random> <Pine.LNX.4.21.0104302335490.19012-100000@imladris.rielhome.conectiva> <20010501071849.A16474@athlon.random> <20010501185517.A31373@athlon.random>
In-Reply-To: <20010501185517.A31373@athlon.random>; from andrea@suse.de on Tue, May 01, 2001 at 18:55:17 +0200
On 05.01 Andrea Arcangeli wrote:
>
> And if you fork off a child with its p->policy SCHED_YIELD set it will
> never get scheduled in.
>
> Only "just" running tasks can have SCHED_YIELD set.
>
> So the below lines are the *right* and most robust approch as far I can
> tell. (plus counter needs to be volatile, as every variable that can
> change under the C code, even while it's probably not required by the
> code involved with current->counter)
>
> > + {
> > + int counter = current->counter >> 1;
> > + current->counter = p->counter = counter;
> > + p->policy &= ~SCHED_YIELD;
> > + current->policy |= SCHED_YIELD;
> > + current->need_resched = 1;
> > + }
>
> Alan, the patch you merged in 2.4.4ac2 can fail like mine, but it may fail in
> a much more subtle way, while I notice if ksoftirqd never get scheduled
> because I synchronize on it and I deadlock, your kupdate/bdflush/kswapd
> may be forked off correctly but they can all have SCHED_YIELD set and
> they will *never* get scheduled. You know what can happen if kupdate
> never gets scheduled... I recommend to be careful with 2.4.4ac2.
>
It looks like this is related to my problem (see thread [Re: Linux-2.4.4-ac2]).
Funtions __start_kernel called kernel_thread(init,...), and seems to hang
on cpu_idle().
--
J.A. Magallon # Let the source
mailto:jamagallon@able.es # be with you, Luke...
Linux werewolf 2.4.4-ac1 #1 SMP Tue May 1 11:35:17 CEST 2001 i686
next prev parent reply other threads:[~2001-05-01 17:33 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.21.0104281928080.10759-100000@penguin.transmeta.com>
2001-04-29 8:26 ` 2.4.4 sluggish under fork load Peter Osterlund
2001-04-30 17:51 ` Andrea Arcangeli
2001-04-30 21:45 ` Peter Osterlund
2001-05-01 2:38 ` Rik van Riel
2001-05-01 5:18 ` Andrea Arcangeli
2001-05-01 16:55 ` Andrea Arcangeli
2001-05-01 17:33 ` J . A . Magallon [this message]
2001-05-01 20:34 ` Alan Cox
2001-05-03 14:02 Hubertus Franke
-- strict thread matches above, loose matches on Subject: below --
2001-05-01 4:18 Adam J. Richter
2001-04-29 8:04 Adam J. Richter
2001-04-29 7:14 Adam J. Richter
2001-04-28 11:52 Peter Osterlund
2001-04-28 14:16 ` J . A . Magallon
2001-04-28 14:26 ` Mohammad A. Haque
2001-04-28 15:07 ` Rene Puls
2001-04-28 17:10 ` John Kacur
2001-04-28 18:00 ` Peter Osterlund
2001-04-28 17:54 ` Linus Torvalds
2001-04-28 19:14 ` Peter Osterlund
2001-04-28 20:00 ` Harald Dunkel
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=20010501193329.C1246@werewolf.able.es \
--to=jamagallon@able.es \
--cc=andrea@suse.de \
--cc=linux-kernel@vger.kernel.org \
/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