lkml.org 
[lkml]   [2003]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] O17int
Quoting Wes Janzen <superchkn@sbcglobal.net>:

> I wish I could get mm3 running so I could evaluate those interactivity
> statements. I can't imagine it being worse than what I'm experiencing now:

Umm. You didn't mention which kernel/patch? I seem to recall you were using
Osomething but which?

> That would be compiling the kernel, bunzipping a file, and some cron
> mandb thing that was running gzip in the background niced. Plus X and
> Mozilla, which probably starts the problem. At the end there, you see
> things calm down. That's also the way it starts out, then something
> sets off the "priority inversion" and the machine becomes completely
> worthless. Even the task that are running aren't really accomplishing
> anything. So the load goes from around 4/5 into the teens and the
> context switching makes a corresponding jump. And then both
> interactivity AND throughput fall through the floor.
>
> I can't imagine any interactivity regressions that are worse than this
> behavior...

If this is Osomething, can you tell me when it started doing this and what
vanilla does.

> And this happens with just X and Mozilla running. It happens less often
> without X running, but still happens. Even if I'm at a VT, it could
> take 5-6 seconds for my text to appear after I type. This happens all
> the time, about once every few minutes and correlates with a
> simultaneous increase in context switches and load.

Ditto

> Can you set a cutoff point where if the process uses less that X percent
> of the max timeslice, it is penalized? I don't know if it's possible
> to do a loop of empty spins at some point and time it to find out what
> the cut-off point should be...otherwise I imagine it would need to be
> tuned for every processor speed. Could you use the bogomips to gauge
> the speed of the machine and use that to determine the min timeslice?
> From what I understand above, that would perhaps be more selective than
> just penalizing every process and have a positive affect on
> everything...of course I'm open to the possibility that I have it all
> wrong ;-)

A thought, but unfortunately some arbitrary limit would just be hit by
everything randomly rather than with any meaningful frequency. The timeslice
interactive things use up is extremely variable depending on circumstances.

Con
-
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/

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