Re: [REPORT] cfs-v4 vs sd-0.44



On Apr 21, 2007, at 12:42:41, William Lee Irwin III wrote:
On Sat, 21 Apr 2007, Willy Tarreau wrote:
If you remember, with 50/50, I noticed some difficulties to fork many processes. I think that during a fork(), the parent has a higher probability of forking other processes than the child. So at least, we should use something like 67/33 or 75/25 for parent/ child.

On Sat, Apr 21, 2007 at 09:34:07AM -0700, Linus Torvalds wrote:
It would be even better to simply have the rule:
- child gets almost no points at startup
- but when a parent does a "waitpid()" call and blocks, it will spread out its points to the childred (the "vfork()" blocking is another case that is really the same).
This is a very special kind of "priority inversion" logic: you give higher priority to the things you wait for. Not because of holding any locks, but simply because a blockign waitpid really is a damn big hint that "ok, the child now works for the parent".

An in-kernel scheduler API might help. void yield_to(struct task_struct *)?

A userspace API might be nice, too. e.g. int sched_yield_to(pid_t).

It might be nice if it was possible to actively contribute your CPU time to a child process. For example:
int sched_donate(pid_t pid, struct timeval *time, int percentage);

Maybe a way to pass CPU time over a UNIX socket (analogous to SCM_RIGHTS), along with information on what process/user passed it That would make it possible to really fix X properly on a local system. You could make the X client library pass CPU time to the X server whenever it requests a CPU-intensive rendering operation. Ordinarily X would nice all of its client service threads to +10, but when a client passes CPU time to its thread over the socket, then its service thread temporarily gets the scheduling properties of the client. I'm not a scheduler guru, but that's what makes the most sense from an application-programmer point of view.

Cheers,
Kyle Moffett

-
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/



Relevant Pages

  • Re: Help on delagate strange behaviour ???
    ... "Doker" wrote: ... register to the so called Client class which raise the events but this is not ... other assembly (The "parent") whcih is the only interface that my final user ... Because Child object definded in Parent one is not the same one defined ...
    (microsoft.public.dotnet.general)
  • Re: Help on delagate strange behaviour ???
    ... And actually I cannot call directly the Insert method becasue I am using an other assembly (The "parent") whcih is the only interface that my final user can use in order to perform that Insert function. ... Because Child object definded in Parent one is not the same one defined in Client app. ... In some situation you can create a parent class by deriving (inheriting) from the child class. ...
    (microsoft.public.dotnet.general)
  • Re: Trapping a page in a frame?
    ... I said the child document - from a different domain - can ... *not* access the URL of the parent. ... Not using 100% client side script. ... MyDomainB and a second iframe from MyDomainC, and I can transfer any data ...
    (comp.lang.javascript)
  • Re: Parent process unable to read messages from child process
    ... 1.A Parent process has to fork to create fixed number of child ... The parent should read each of these values from pipe output of all ... Fork work correct, Child processes compute the correct value, however ... Since $client is what can_read returned, ...
    (comp.lang.perl.misc)
  • Re: CreateProcess API performance question
    ... >> I've got a Delphi app that's spawning a child process via CreateProcess. ... That reduces the parent's overhead to 1%-2% CPU time, but the Idle task then runs at ... Strangely, if I switch back to HIGH_PRIORITY_CLASS, then both the parent and child ...
    (borland.public.delphi.nativeapi)