On Mon, Aug 06 2007, Andi Kleen wrote:
quoted text
> > couldn't this be fixed by bumping idle tasks to middle while they hold a 
> 
> Usually to high.
> 
> But it's all complicated and hasn't been done consistently
> (there are real time mutexes in the -rt kernel for example, 
> but there are lots of other locks and they have higher overhead too) 
> and it's unclear we really want to do all this complexity anyways.
> 
> Also as I said the problem could then still happen in user space
> which then would all need to be fixed to handle PI too.
> 
> In some cases the relationship is also not as simple as a single 
> lock. And for IO handling it would be likely quite hard.
> 
> I personally always found idle priorities quite dubious because
> even if they worked reliable for the CPU they will clear your cache/
> load your memory controller and impact all other programs because
> of this. And for the disk they will cause additional seeks which are 
> also very costly.

But that is why the idle priority implementation in CFQ adds a grace
period before idle prio tasks are run. So that concern should not be an
issue, if so the grace period needs to be enlarged. That at least covers
the seek side of things. If idle io tasks run, then the IO load on the
system must be very low to zero. Hence other IO relevant resource
contention isn't an iissue.

-- 
Jens Axboe

-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/