Re: Feature proposal (scheduling related) -- conclusion

Re: Feature proposal (scheduling related) -- conclusion

[jimis]

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

Re: Feature proposal (scheduling related) -- conclusion

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]

On Tue, 29 Jul 2003 22:28:50 +0300, jimis@gmx.net  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....


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Feature proposal (scheduling related) -- conclusion

[Dimitris Apostolou]

Valdis.Kletnieks@vt.edu 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

Re: Feature proposal (scheduling related) -- conclusion

[Pavel Machek]

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...