[lkml]   [2002]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] improving O(1)-J9 in heavily threaded situations
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

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:

- Jussi Laako

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:23    [W:0.049 / U:6.368 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site