Re: [PATCH] improving O(1)-J9 in heavily threaded situations

[Jussi Laako <jussi.laako@kolumbus.fi>]

Ingo Molnar wrote:
> 
> 'response' in terms of interactive latencies should be good, yes.
> 
> 'response' in terms of relative CPU time given to CPU hogs and 
> interactive tasks wont be as 'good' as with the old scheduler. (ie. CPU 
> hogs *will* be punished harder - this is what is needed for good 
> interactivity after all.) So if you see that some of your interactive 

How about priority inheritance? When interactive task relies heavily on
output from CPU hog?

My application uses three tier architecture where is low HAL layer reading
audio from soundcard which is compressed and sent (TCP) to distributor
process which decompresses the audio and distributes (UNIX/LOCAL) it to
clients. Distributor's clients are the CPU hogs doing various processing
tasks to the signal and then sending (TCP) the results to the very thin user
interface.

Now the user interface can take some CPU time and is considered to be
interactive. But if that leads to starvation of CPU hog processing tasks it
leads to unusable output on user interface because starvation leads to
losing blocks of data in distributor process.

HAL and distributor are running as SCHED_FIFO, but CPU hog processing tasks
are dynamically fork()/exec()'d and run on default priority (not as root).
So I should nice user interfaces to 15+?

App can be found from: http://hasas.sf.net


	- Jussi Laako

-- 
PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B  39DD A4DE 63EB C216 1E4B
Available at PGP keyservers