Messages in this thread | | | Date | Mon, 2 Jan 2006 12:01:45 +0100 | Subject | Re: [PATCH] sched: Fix adverse effects of NFS client on interactive response | From | 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |