In article <24d4r1INN6qr@galaxy.uci.agh.edu.pl> szymon@galaxy.uci.agh.edu.pl (Szymon Sokol) writes:
>: Be careful of using nice on anything that isn't CPU bound. I believe
>: it's possible for the scheduling and paging algorithms to interfere
>: adversely. (I'm having trouble thinking of a watertight example
>: though, so maybe this is just urban legend.)
>
> This is interesting. Recently we had a user who allocated much more memory
> to his process than the size of physical RAM, so the machine was paging
> heavily. 'renice' did not help much, because the bottleneck was on the
> disk, not on the CPU (in fact, CPU was used in ~70% only - our 690 has 2
> CPUs). I wonder though, if the problem mentioned above (the interference
> between the scheduling and paging algorithms) really exists, and if so -
> how does it affect performance.
I'm not really sure, but I doubt this really happens. The nice only comes
into effect in the scheduling algorithm for the run queues (32 of them
in SunOS 4.x, only 1 in System V, I believe). If a process is waiting for
a page to be swapped back in, it's not in a run queue, so the nice value
probably shouldn't matter.
Of course, what could happen is that since a niced-down process gets
relatively few timeslices, its pages tend to get paged out more often (they
haven't been used in a while), so when it finally gets a timeslice, it
has to wait for the pages to be paged back in, making it slower still.
Nonetheless, I wouldnt think of this as "adverse interference" between
the two algorithms...
-- Mark Sirota, System and Network Manager Greenwich Associates, Greenwich Connecticut mark@greenwich.com, (203) 625-5060
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:06 CDT