Messages in this thread | | | Date | Wed, 06 Aug 2003 17:33:19 -0400 | From | Timothy Miller <> | Subject | Re: [PATCH] O13int for interactivity |
| |
Nick Piggin wrote:
> If cc1 is doing a lot of waiting on IO, I fail to see how it should be > called a CPU hog. OK I'll stop being difficult! I understand the problem > is that its behaviour suddenly changes from IO bound to CPU hog, right? > Then it seems like the scheduler's problem is that it doesn't adapt > quickly enough to this change. > > What you are doing is restricting some range so it can adapt more quickly > right? So you still have the problem in the cases where you are not > restricting this range.
For this, I reiterate my suggestion to intentionally over-shoot the mark. If you do it right, a process will run an inappropriate length of time only every other time slice until the oscillation dies down.
Let me give you an example. Let's say you have a process which is being interactive, and then suddenly becomes a CPU hog.
In the case as it is (assumptions here), what happens is that the priority is reduced by some amount until it reaches a level appropriate for the new behavior.
I get the impression that lower numbers mean higher priority, so here goes:
- The process starts out with a priority of 10 (this may mean something that I don't know about... just follow along). - It becomes a CPU hog sufficient to make it NEED to be at a priority of 30. - Over some number of time slices, the priority is changed something like this: 10, 20, 25, 27, 28, 29, 30.
Here's my alternative suggestion -- if 10 is pure interactive and 30 is CPU hog, and you see some change in behavior, before, you would go half way. Now, instead, go one-and-a-half way. - Over some number of time slices, the priority is changed like this: 10, 40, 25, 32, 27, 31, 28, 30
Let's say that you only get one time slice which is CPU hog, but others are not, for the first case, you'd get something like this: 10, 20, 15, 12, 11, 10
For the second case, you'd get this: 10, 40, -5, 17, 7, 11, 10
Something like that. So instead of getting tricked and having to return, it over shoots but makes up for it the next time the process is run.
This is a very incomplete thought and may be pure garbage, so please forgive me if I'm being an idiot. :)
- 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/
| |