Messages in this thread | | | Date | Fri, 15 Jan 1999 01:46:04 +0100 (CET) | From | Rik van Riel <> | Subject | Re: [uPATCH] SMP scheduling fix (?) |
| |
On Fri, 15 Jan 1999, MOLNAR Ingo wrote: > On Thu, 14 Jan 1999, Rik van Riel wrote: > > > [...] In fact, > > you often see that 2 non-niced tasks have to share a > > CPU while 2 niced tasks get the other CPU... > > (Do you have some (simple or complex) testcase where we fail?)
Yes, 2 niced +20 tasks taking up one CPU where 2 normal tasks (one using full CPU and X) taking up the other. The 'Right Thing' would be to let X switch to the other CPU and bother the niced tasks...
> > This is probably because the PROC_CHANGE_PENALTY is > > _larger_ than the priority of the niced task to begin > > with, so the niced task gets it's priority more than > > doubled and the normal task can't get through... > > ? it doesnt matter wether it's doubled or not, being on the > 'previous' CPU means it gets an (absolute) goodness boost.
But if this boost puts it above a normal task it means that two normal tasks will bother eachother on one CPU and one (or two) niced tasks take up the other. Not Good :(
> > This patch may fix the problem by giving a large bonus > > to 'normal' processes and a smaller one to niced tasks. > > why? SMP + caching issues are the same no matter what priority the > task has. Priority is mainly a way to control CPU-bound processes. > (interactive processes will have maximum priority anyway)
While interactive processes may have maximum priority, I'd like it if the kernel would take a non-niced process from another CPU above a niced task from the current CPU when my editor is done. That way the non-niced tasks would tend to get out of eachother's way, only bothering the niced tasks and not eachother.
> > It also removes the standard 'weight += p->priority' > > because that one was a workaround for the bug in tty_ioctl.c > > and we shouldn't need it any more now that that's fixed. > > no. the point as i understand it is to have high statical priority > tasks getting scheduled before lowprio tasks, even if the higher > priority task has used up most of it's timeslice.
Whoops, this was a definite brain fart on my side. We should probably ignore the thing and get some bugfixes done for 2.2. After that I'll continue the scheduler bigpatch and play with things like this a bit...
cheers,
Rik -- If a Microsoft product fails, who do you sue? +-------------------------------------------------------------------+ | Linux memory management tour guide. riel@nl.linux.org | | Scouting Vries cubscout leader. http://www.nl.linux.org/~riel | +-------------------------------------------------------------------+
- 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/
| |