[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.024 / U:49.236 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site