On Fri, 15 Jan 1999, Jeffrey Mark Siskind wrote:
> Basically, I think that the nice level needs to affect not only
> time slices in the scheduler but also page-in or disk-access
> priority. Is that possible?
Of course it's possible -- we could simply change jiffies
for each major fault. Problem is that that doesn't help you
with your interactive response (which will surely suffer
from the load your big job places either by taking in a lot
of memory or by using a lot of I/O [when RSS limits are there]).
The only nonobtrusive solution (for now) is to suspend the
program when you're at the console.
A more advanced, long-term, solution would be to throttle
the page fault rate of huge jobs when we're short on memory.
Something like:
if (been_swapping_lately &&
have_swapped_in_multiple_processes &&
current->mm->rss > HUGE)
throttle_current_process();
I think we want to limit a niced task to a rather
small number of disk I/O operations a second (proportional
to some measured average we measured and proportional to
the nice level of the process in question).
cheers,
Rik -- If a Microsoft product fails, who do you sue?
+-------------------------------------------------------------------+
| Linux memory management tour guide. [EMAIL PROTECTED] |
| Scouting Vries cubscout leader. http://www.nl.linux.org/~riel |
+-------------------------------------------------------------------+
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
