lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 7 Aug 2007 22:44:51 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	dragoran <drago01@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: allow non root users to set io priority "idle" ?

On Mon, Aug 06 2007, Andi Kleen wrote:
> > 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

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ