Messages in this thread | | | Date | Thu, 7 Jan 1999 00:20:37 +0100 (CET) | From | MOLNAR Ingo <> | Subject | Re: [patch] agv_slice not initialized |
| |
On Tue, 5 Jan 1999, David S. Miller wrote:
> Ok, we don't have a precise better guess, but the situation is real. > It's wildly inaccurate for very common activities, even a kernel > build. Think about what happens to make, gcc, and their children as > they each begin to do their work.
note that for kernel builds the typical timeslice is way beyond the 'cacheflush limit' anyway, so the real value of avg_slice makes no difference. Explicitly setting it to zero might cause the child to be considered as a 'gang' member, and thats bogus.
> Here is a quick idea. How about halfing it? Then in about 2 > timeslices we'll be approximate, even less if the child's average > slice is significantly smaller than the parents.
we do that for the p->counter timeslice counter, but the p->avg_slice value is 'invariant' for CPU-bound processes and does not depend on the number of CPU-bound processes running in the system. (because it does not account for time spent sleeping, on purpose)
it's not all that important to get avg_slice right immediately, unless the process will do only a few reschedules in it's lifetime. (in that case it's important not to make avg_slice _bigger_, to not lose a possible gang membership)
in any other case, it's important to not make the slice _smaller_ than the real value, ie. it might happen that halving avg_slice will put child and parent into a gang relationship, which is not justified.
leaving it untouched sounds like the best choice. (in the already mentioned exec() case it might make sense to set avg_slice to some large and constant value, because freshly exec()-ed processes tend to be pretty heavyweight)
-- mingo
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |