Kyle Moffett wrote:
On Dec 21, 2005, at 11:10, Horst von Brand wrote:
Kyle Moffett <[email protected]> wrote:
On Dec 21, 2005, at 08:21, Trond Myklebust wrote:
...and if you stick in a faster server?...
There is _NO_ fundamental difference between NFS and a local
filesystem that warrants marking one as "interactive" and the other
as "noninteractive". What you are basically saying is that all I/O
should be marked as TASK_NONINTERACTIVE.
Uhh, what part of disk/NFS/filesystem access is "interactive"?
Which of those sleeps directly involve responding to user- interface
events?
And if it is a user waiting for the data to display? Can't
distinguish that so easily from the compiler waiting for something to
do...
No, but in that case the program probably _already_ has some
interactivity bonus just from user interaction.
And if it doesn't then it is (by definition) not interactive. :-)
As you imply, this change is targetting those tasks whose ONLY
interruptible sleeps are due to NFS use.
On the other hand, UI
programming guidelines say that any task which might take more than a
half-second or so should not be run in the event loop, but in a
separate thread (either a drawing thread or similar). In that case,
your event loop thread is the one with the interactivity bonus, and the
others are just data processing threads (like the compile you have
running in the background or the webserver responding to HTTP
requests), that the user would need to manually arbitrate between with
nice levels.
The whole point of the interactivity bonus was that processes that
follow the cycle <waiting-for-input> => <respond-to-input-for-less-
than-time-quantum> => <waiting-for-input> would get a boost; things
like dragging a window or handling mouse or keyboard events should
happen within a small number of milliseconds, whereas background tasks
really _don't_ care if they are delayed running their time quantum by
400ms, as long as they get their full quantum during each cycle.
Exactly. It's all about latency and doesn't really effect the
allocation of CPU resources according to niceness as that is handled via
differential time slice allocations.
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]
