NOTICE: This forum is mostly an archive, though new posts are allowed. Registration may require manual admin activation. After registering visit https://bitsum.com/contact/ to request account activation.
Started by adx, June 29, 2009, 12:28:28 AM
Quote from: jeremy.collake on July 03, 2009, 11:38:26 AM I think I can tweak the CPU throttling code so that I/O throttling is also induced, as an inherent side-effect of the CPU throttling. That may solve the problems of most users, and be simple to implement at the same time.
Quote from: knolle on July 03, 2009, 11:52:34 AMdefenetly and let users chose witch prosses to implement this new I/O throttling for exampe some HD recording software uses a lot of resurses but you dont want to restrain them
QuoteBut CPU is allocated in time slices, as far as I know in round robin style, so if I/O requests are processed on a first come first served basis then all applictions should get a look in? Within one cycle of the scheduler too, especially if the "good" task is the foreground task. Maybe the "evil" task can bypass the CPU scheduler (eg interrupt/event driven chaining of read requests).
Quote from: adx on July 03, 2009, 11:46:15 PMPerhaps some guesses can be made based on latency, reads, data rate, and possibly whether the requests are for different files (implying a lot of time spent seeking)?
QuoteNo, I'm still a bit confused about the sharing criteria. What's important is the way I/O "time" is shared between tasks, ie you need to know how long the I/O channel is spending on each request for each task, not the total latency for each task's I/O. In my example above the foreground task may have been waiting 20 seconds but has probably received 0 seconds of I/O time. It may be that Windows doesn't provide this info?