Messages in this thread |  | | | Date | Tue, 1 May 2001 19:33:29 +0200 | | From | "J . A . Magallon" <> | | Subject | Re: 2.4.4 sluggish under fork load |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |