Thank you all very much for your answers, I 've learned a lot. However I have
some comments to make concerning the two proposals I made:
1) Network traffic scheduling. I 've studied a little the linux advanced routing
and traffic control HOWTO and the wondershaper script and I think they are
great, I had no idea of this potential. But what I propose is scheduling the
network traffic (at least the outgoing traffic that we can influence directly)
according to the process priority, not according to the traffic type (which is
important but different).
2) Disk I/O scheduling, again according to the process priority. From some posts
I found out that there was a patch that did that, but I don't know where it is
or if it is up to date with newer kernels.
I hope I clarified myself and I believe these features would be useful if
included in the kernel.
Thanks,
Dimitris
P.S. Please forward me any replies
On Tue, 29 Jul 2003 22:28:50 +0300, [email protected] said:
> great, I had no idea of this potential. But what I propose is scheduling the
> network traffic (at least the outgoing traffic that we can influence directly)
> according to the process priority, not according to the traffic type (which is
> important but different).
So you want to use a number that controls the CPU scheduling to force the network
scheduling to go along? That's a bad idea waiting to happen.
(Hint - some program is getting CPU-starved for some reason, so you 'nice -2' it
to make it run tolerably. Suddenly your icecast gets stomped on. Whoops)
It's even worse if you're trying to use dynamic priorities - then your icecast
can get pushed to the bottom of the network pile because some other process
went super-interactive for a while...
Remember - you're trying to optimize the "network experience" for the
*connection*. Base it on the port numbers, or use the process's UID and run
your program under a seperate UID, or maybe a PID-based scheme, with an ioctl()
or /{proc,sys} based control....
[email protected] wrote:
>
> So you want to use a number that controls the CPU scheduling to force the network
> scheduling to go along? That's a bad idea waiting to happen.
>
Read my initial posting, what I propose is defining priorities for net and disk
I/O independant to CPU priority
Hi!
> > great, I had no idea of this potential. But what I propose is scheduling the
> > network traffic (at least the outgoing traffic that we can influence directly)
> > according to the process priority, not according to the traffic type (which is
> > important but different).
>
> So you want to use a number that controls the CPU scheduling to force the network
> scheduling to go along? That's a bad idea waiting to happen.
>
Hint: he's right.
By default it is reasonable to give lower disk priority to nice -19 tasks. In some cases that
breaks, so cpu_nice, disk_nice etc. would be better.
Pavel
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...