[lkml]   [1999]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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...


Rik -- If a Microsoft product fails, who do you sue?
| Linux memory management tour guide. |
| Scouting Vries cubscout leader. |

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:49    [W:0.065 / U:3.668 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site