Trond Myklebust wrote:
On Fri, 2005-12-23 at 14:06 +1100, Peter Williams wrote:
As far as a filesystem is concerned, there should be 2 scheduling
states: running and sleeping. Any scheduling policy beyond that belongs
in kernel/*.
Actually there are currently two kinds of sleep: interruptible and
uninterruptible. This just adds a variation to one of these,
interruptible, that says even though I'm interruptible I'm not
interactive (i.e. I'm not waiting for human intervention via a key
press, mouse action, etc. to initiate the interrupt). This helps the
scheduler to decide whether the task involved is an interactive one or
not which in turn improves users' interactive experiences by ensuring
snappy responses to keyboard and mouse actions even when the system is
heavily loaded.
No! This is not the same thing at all.
You are asking the coder to provide a policy judgement as to whether or
not the users might care.
No. It is asking whether the NORMAL interruption of this interruptible
sleep will be caused by a human user action such as a keystroke or mouse
action. For the NFS client the answer to that question is unequivically
no. It's not a matter of policy it's a matter of fact.
As far as I'm concerned, other users' MP3 player, X processes, and
keyboard response times can rot in hell whenever I'm busy writing out
data at full blast. I don't give a rats arse about user interactivity,
because my priority is to see the batch jobs complete.
However on another machine, the local administrator may have a different
opinion. That sort of difference in opinion is precisely why we do not
put this sort of policy
It's not policy. It's a statement of fact about the nature of the sleep
that is being undertaken.
in the filesystem code but leave it all in the
scheduler code where all the bits and pieces can (hopefully) be treated
consistently as a single policy, and where the user can be given tools
in order to tweak the policy.
TASK_NONINTERACTIVE is basically a piss-poor interface because it moves
the policy into the lower level code where the user has less control.
TASK_INTERACTIVE is not about policy.
There are probably many interruptible sleeps in the kernel that should
be marked as non interactive but for most of them it doesn't matter
because the duration of the sleep is so short that being mislabelled
doesn't materially effect the decision re whether a task is interactive
or not. However, for reasons not related to the quality or efficiency
of the code, NFS interruptible sleeps do not fall into that category as
they can be quite long due to server load or network congestion. (N.B.
the size of delays that can be significant is quite small i.e. much less
than the size of a normal time slice.)
An alternative to using TASK_NONINTERACTIVE to mark non interactive
interruptible sleeps that are significant (probably a small number)
would be to go in the other direction and treat all interruptible sleeps
as being non interactive and then labelling all the ones that are
interactive as such. Although this would result in no changes being
made to the NFS code, I'm pretty sure that this option would involve a
great deal more code changes elsewhere as all the places where genuine
interactive sleeping were identified and labelled.
That is exactly the same rotten idea, just implemented differently.
I thought that I said (or at least implied) that. The difference is
that we wouldn't be having this conversation.
You
are still asking coders to guess as to what the scheduling policy should
be instead of letting the user decide.
I wish that I could make you understand that that isn't the case.
You're not being asked to make a policy decision you're being asked to
make a statement of fact about whether the interruptible sleep is
interactive or not. In the cases involved in this patch this question
is always "no, it's not an interactive" sleep and it can be answered at
compile time with absolutely no run time overhead incurred.
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]
