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

[Peter Williams <pwil3058@bigpond.net.au>]

Ingo Molnar wrote:
> * Peter Williams <pwil3058@bigpond.net.au> 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                                   pwil3058@bigpond.net.au

"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 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/