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.
>
>   
ok, thx so that means that the best that can be done for now is to run 
beagle as best effort with prio 7 (like its done now).


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