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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ingo Molnar wrote:
* Peter Williams <[email protected]> wrote:


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. [...]


could you try the build with the scheduler queue from -mm, and set the shell to SCHED_BATCH first? Do you still see interactivity problems after that?

There's no real point in doing such a test as running the build as SCHED_BATCH would obviously prevent its tasks from getting any interactive bonus. So I'll concede that is a solution.

However, the problem I see with this solution is that it's pushing the onus onto the user and forcing them to decide/remember to run non interactive tasks as SCHED_BATCH (and I see the whole point of the interactive responsiveness embellishments of the scheduler being to free the user of the need to worry about these things). It's a marginally better solution than its complement i.e. marking interactive tasks as being such via putting them in a (hypothetical) SCHED_IA class because that would clearly have to be a privileged operation unlike setting SCHED_BATCH.

This is a case where the PAGG patches would have been useful. With them a mechanism for monitoring exec()s and shifting programs to SCHED_BATCH based on what program they had just exec()ed would be possible making SCHED_BATCH a better solution to this problem. If PAGG were complimented with a kernel to user space event notification mechanism the bulk of this could be accomplished in user space. The new code SGI is proposing as an alternative to PAGG may meet these requirements?


i'm not sure we want to override the scheduling patterns observed by the kernel, via TASK_NONINTERACTIVE - apart of a few obvious cases.

I thought that this was one of the obvious cases. I.e. interruptible sleeps that clearly aren't interactive.

I interpreted your statement "Right now only pipe_wait() will make use of it, because it's a common source of not-so-interactive waits (kernel compilation jobs, etc.)." in the original announcement of TASK_INTERACTIVE to mean that it was a "work in progresss" and would be used more extensively when other places for its application were identified.

BTW I don't think that it should be blindly applied to all file system code as I tried that and it resulted in the X server not getting any interactive bonus with obvious consequences :-(. I think that use of TASK_NONINTERACTIVE should be done carefully and tested to make sure that it has no unexpected scheduling implications (and I think that this is such a case). Provided the TASK_XXX flags are always treated as such there should be no changes to the semantics or efficiency (after all, it's just an extra bit in an integer constant set at compile time) of any other code (than the scheduler's) as a result of its use.

Peter
--
Peter Williams                                   [email protected]

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux