Re: allow non root users to set io priority "idle" ?

[Bodo Eggert]

Andi Kleen <andi@xxxxxxxxxxxxxx> wrote:

>> couldn't this be fixed by bumping idle tasks to middle while they hold a
> 
> Usually to high.

Then use the lowest non-idle priority. The result will not be more b0rken
than nice -n 19.

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

If you have an rt application, it will block normal tasks like a normal
task will block idle tasks. You need to handle that situation anyway.

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

Don't do that then. If I ask an idle priority task, I should not expect an
answer unless the system is idle. And besides that, I should not depend on
an answer at all, since the task might be stuck while reading a NFS file
from that smoking and burning server.

> In some cases the relationship is also not as simple as a single
> lock. And for IO handling it would be likely quite hard.

As long as IO works correctly while having realtime tasks, there is no
problem, and if it doesn't work, it needs to be fixed anyway.

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

A very-low-normal-priority tasks would cause all these effects anyway, but
it would do so more frequently.
-- 
Top 100 things you don't want the sysadmin to say:
74. I remember the last time I saw it do that...

Friß, Spammer: jf@xxxxxxxxxxxxxxxxxx rqfpzq@xxxxxxxxxxxxxxxxxxxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/