Re: [PATCH] Performance regression in 2.6.7-rc3

[Martin J. Bligh]

>> > How the hell can that have any effect on non-threaded workloads? Perhaps
>> > some part of kernel compile *is* multi-threaded. It does seem to get 
>> 
>> make(1) with vfork(2) perhaps?
> 
> Very likely. And in the vfork() case it is definitely WRONG to try to
> reschedule (either threads _or_ processes), since the parent is going to
> go to sleep real soon now.
> 
> I think this code:
> 
>                         if (clone_flags & CLONE_VM)
>                                 wake_up_forked_thread(p);
>                         else
>                                 wake_up_forked_process(p);
> 
> is just wrong, and it should be replaced with
> 
> 			wake_up_new_process(p, clone_flags);
> 
> and then "wake_up_new_process()" can do the right thing, which is 
> basically:
> 
> 	if (clone_flags & CLONE_VFORK)
> 		synchronous wakeup, same as pipe-will-block case
> 	else if (clone_flags & CLONE_VM)
> 		thread-wakeup-case
> 	else
> 		process-wakeup-case
> 
> No?

Looks much better ... but I'd still dispute whether we need to throw 
non-vfork threads cross node by default. I'd suggest that's disabled
by default, and is either enabled by a global userspace option, or a
per-process one (or the option of both). Most thing (except benchmarks)
simply don't want this in real life ...

M.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/