Re: [PATCH] sched: Fix adverse effects of NFS client on interactive response

[Helge Hafting]

On Wed, Dec 21, 2005 at 05:32:52PM +1100, Peter Williams wrote:
> Trond Myklebust wrote:
[...]
> >
> >Sorry. That theory is just plain wrong. ALL of those case _ARE_
> >interactive sleeps.
> 
> It's not a theory.  It's a result of observing a -j 16 build with the 
> sources on an NFS mounted file system with top with and without the 
> patches and comparing that with the same builds with the sources on a 
> local file system.  Without the patches the tasks in the kernel build 
> all get the same dynamic priority as the X server and other interactive 
> programs when the sources are on an NFS mounted file system.  With the 
> patches they generally have dynamic priorities between 6 to 10 higher 
> than the X server and other interactive programs.
> 
A process waiting for NFS data looses cpu time, which is spent on running 
something else.  Therefore, it gains some priority so it won't be
forever behind when it wakes up.  Same as for any other io waiting.

Perhaps expecting a 16-way parallel make to have "no impact" is
a bit optimistic.  How about nicing the make, explicitly telling
linux that it isn't important?  Or how about giving important
tasks extra priority?

Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/