linux-kernel - Re: [PATCH][RSDL-mm 4/6] sched: dont renice kernel threads

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] [day] [month] [year] [list]

Message-Id: <200703170829.47810.kernel@kolivas.org>
Date:	Sat, 17 Mar 2007 08:29:47 +1100
From:	Con Kolivas <kernel@...ivas.org>
To:	"Chris Friesen" <cfriesen@...tel.com>
Cc:	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	ck list <ck@....kolivas.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH][RSDL-mm 4/6] sched: dont renice kernel threads

On Saturday 17 March 2007 02:14, Chris Friesen wrote:
> Con Kolivas wrote:
> > The practice of renicing kernel threads to negative nice values is of
> > questionable benefit at best, and at worst leads to larger latencies when
> > kernel threads are busy on behalf of other tasks.
>
> What about the priority implications of the renicing?  It seems a bit
> iffy letting kernel threads compete for cpu time on an equal basis with
> your default shell.

Lots of things we do because we just assume they're a good idea without any 
evidence. Renicing kernel threads was always considered a good idea on this 
basis. I'm certain noone has ever proven that it's a good thing though. 
Either way, the latest version of rsdl is robust enough that it works fine 
with reniced kernel threads if you still believe that's advantageous. This is 
definitely open for discussion/opinion.

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