Feature proposal (scheduling related) -- conclusion
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
Quoted 4 lines · 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....
Quoted 4 lines · [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!
Quoted 8 lines
Quoted 4 lines
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
Signature · 2 lines
Pavel Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...