Re: 2.4.4 fork.c changes cause linuxconf to fail
Jeff Garzik wrote: >Michael Pakovic wrote: >> The changes to kernel/fork.c from 2.4.4-pre1 to 2.4.4-pre3 (and in >> 2.4.4) cause the RedHat 6.2 linuxconf utility to fail with the message >> "broken pipe". The linuxconf utility will run the first time, but all >> subsequent runs give the "broken pipe" error. The error message is >> generated as a result of a fflush command in linuxconf. I can provide >> more information upon request. >This patch is definitely breaking things, but AFAIK the fork.c change >only breaks buggy applications... Adam would you say that assertion is >correct? Yes, and they're probably all bugs that were biting us sporadically before. We should take the opportunity to squash them while they're out in the open. We'd better squash those bugs quickly too, because Peter Osterlund has produced a patch that runs the child first without giving all of the CPU allocation to the child, and this apparently is enough to eliminate the problems people have been seeing while retaining the benefit of running the child first. So, I imagine 2.4.5 will not expose these problems. Peter emailed his patch to linux-kernel, but, for some reason, I have only seen the copy that was cc'ed directly to me. I have tried his patch and added two lines so that the child is still run first even when current->counter == 0 (stealing some CPU allocation to do so). I have not benchmarked it, but I do know from testing that without my addition, the parent would still run first about a 1/4-1/5th of the time (consistent with the Linux's allocation of 5 ticks to a regular priority process), and, with this patch, that reduces to about 1/30th. If the performance benefit of running the child first is noticible on bencharks, it should be worth doing it the other 20% of the time as well. Anyhow, here is my modification of Peter Osterlund's patch, against 2.4.4: --- linux-2.4.4/kernel/fork.c Thu Apr 26 06:11:17 2001 +++ linux/kernel/fork.c Mon Apr 30 00:37:30 2001 @@ -666,16 +666,20 @@ p->pdeath_signal = 0; /* -* Give the parent's dynamic priority entirely to the child. The -* total amount of dynamic priorities in the system doesn't change -* (more scheduling fairness), but the child will run first, which -* is especially useful in avoiding a lot of copy-on-write faults -* if the child for a fork() just wants to do a few simple things -* and then exec(). This is only important in the first timeslice. -* In the long run, the scheduling behavior is unchanged. +* "share" dynamic priority between parent and child, thus the +* total amount of dynamic priorities in the system doesn't change, +* more scheduling fairness. The parent yields to let the child run +* first, which is especially useful in avoiding a lot of +* copy-on-write faults if the child for a fork() just wants to do a +* few simple things and then exec(). This is only important in the +* first timeslice. In the long run, the scheduling behavior is +* unchanged. */ - p->counter = current->counter; - current->counter = 0; + p->counter = (current->counter + 1) >> 1; + if (p->counter == 0) + p->counter = 1; + current->counter >>= 1; + current->policy |= SCHED_YIELD; current->need_resched = 1; /* - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 fork.c changes cause linuxconf to fail
Jeff Garzik wrote: Michael Pakovic wrote: The changes to kernel/fork.c from 2.4.4-pre1 to 2.4.4-pre3 (and in 2.4.4) cause the RedHat 6.2 linuxconf utility to fail with the message broken pipe. The linuxconf utility will run the first time, but all subsequent runs give the broken pipe error. The error message is generated as a result of a fflush command in linuxconf. I can provide more information upon request. This patch is definitely breaking things, but AFAIK the fork.c change only breaks buggy applications... Adam would you say that assertion is correct? Yes, and they're probably all bugs that were biting us sporadically before. We should take the opportunity to squash them while they're out in the open. We'd better squash those bugs quickly too, because Peter Osterlund has produced a patch that runs the child first without giving all of the CPU allocation to the child, and this apparently is enough to eliminate the problems people have been seeing while retaining the benefit of running the child first. So, I imagine 2.4.5 will not expose these problems. Peter emailed his patch to linux-kernel, but, for some reason, I have only seen the copy that was cc'ed directly to me. I have tried his patch and added two lines so that the child is still run first even when current-counter == 0 (stealing some CPU allocation to do so). I have not benchmarked it, but I do know from testing that without my addition, the parent would still run first about a 1/4-1/5th of the time (consistent with the Linux's allocation of 5 ticks to a regular priority process), and, with this patch, that reduces to about 1/30th. If the performance benefit of running the child first is noticible on bencharks, it should be worth doing it the other 20% of the time as well. Anyhow, here is my modification of Peter Osterlund's patch, against 2.4.4: --- linux-2.4.4/kernel/fork.c Thu Apr 26 06:11:17 2001 +++ linux/kernel/fork.c Mon Apr 30 00:37:30 2001 @@ -666,16 +666,20 @@ p-pdeath_signal = 0; /* -* Give the parent's dynamic priority entirely to the child. The -* total amount of dynamic priorities in the system doesn't change -* (more scheduling fairness), but the child will run first, which -* is especially useful in avoiding a lot of copy-on-write faults -* if the child for a fork() just wants to do a few simple things -* and then exec(). This is only important in the first timeslice. -* In the long run, the scheduling behavior is unchanged. +* share dynamic priority between parent and child, thus the +* total amount of dynamic priorities in the system doesn't change, +* more scheduling fairness. The parent yields to let the child run +* first, which is especially useful in avoiding a lot of +* copy-on-write faults if the child for a fork() just wants to do a +* few simple things and then exec(). This is only important in the +* first timeslice. In the long run, the scheduling behavior is +* unchanged. */ - p-counter = current-counter; - current-counter = 0; + p-counter = (current-counter + 1) 1; + if (p-counter == 0) + p-counter = 1; + current-counter = 1; + current-policy |= SCHED_YIELD; current-need_resched = 1; /* - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 fork.c changes cause linuxconf to fail
Michael Pakovic wrote: > The changes to kernel/fork.c from 2.4.4-pre1 to 2.4.4-pre3 (and in > 2.4.4) cause the RedHat 6.2 linuxconf utility to fail with the message > "broken pipe". The linuxconf utility will run the first time, but all > subsequent runs give the "broken pipe" error. The error message is > generated as a result of a fflush command in linuxconf. I can provide > more information upon request. This patch is definitely breaking things, but AFAIK the fork.c change only breaks buggy applications... Adam would you say that assertion is correct? Looking at the fork info in SuS v2[1], it doesn't seem to imply any execution order... http://www.opengroup.org/onlinepubs/007908799/xsh/fork.html Jeff -- Jeff Garzik | Game called on account of naked chick Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.4 fork.c changes cause linuxconf to fail
The changes to kernel/fork.c from 2.4.4-pre1 to 2.4.4-pre3 (and in 2.4.4) cause the RedHat 6.2 linuxconf utility to fail with the message "broken pipe". The linuxconf utility will run the first time, but all subsequent runs give the "broken pipe" error. The error message is generated as a result of a fflush command in linuxconf. I can provide more information upon request. Mike Pakovic - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.4 fork.c changes cause linuxconf to fail
The changes to kernel/fork.c from 2.4.4-pre1 to 2.4.4-pre3 (and in 2.4.4) cause the RedHat 6.2 linuxconf utility to fail with the message broken pipe. The linuxconf utility will run the first time, but all subsequent runs give the broken pipe error. The error message is generated as a result of a fflush command in linuxconf. I can provide more information upon request. Mike Pakovic - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 fork.c changes cause linuxconf to fail
Michael Pakovic wrote: The changes to kernel/fork.c from 2.4.4-pre1 to 2.4.4-pre3 (and in 2.4.4) cause the RedHat 6.2 linuxconf utility to fail with the message broken pipe. The linuxconf utility will run the first time, but all subsequent runs give the broken pipe error. The error message is generated as a result of a fflush command in linuxconf. I can provide more information upon request. This patch is definitely breaking things, but AFAIK the fork.c change only breaks buggy applications... Adam would you say that assertion is correct? Looking at the fork info in SuS v2[1], it doesn't seem to imply any execution order... http://www.opengroup.org/onlinepubs/007908799/xsh/fork.html Jeff -- Jeff Garzik | Game called on account of naked chick Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
