linux-kernel - Re: [patch] f83f9ac causes tasks running at MAX

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:	Thu, 03 Dec 2009 11:25:33 +1000
From:	Peter Williams <pwil3058@...pond.net.au>
To:	Mike Galbraith <efault@....de>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>
CC:	LKML <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [patch]  f83f9ac causes tasks running at MAX_PRIO

On 02/12/09 22:49, Mike Galbraith wrote:
> Hysterical reasons?  That might have been a doorstop conversion kit for
> O(1), but boots fine with CFS, and prio 40 tasks are history.

In my (not so) humble opinion, there is still a lot of unnecessary cruft 
in sched.c that should have been removed as the final (clean up) stage 
of implementing CFS (i.e. stuff that was needed for O(1) but no longer 
serves a useful purpose).  I know that the extra overhead of this code 
is probably inconsequential (and the compiler may even optimize some of 
it away) but it looks untidy and makes the code harder to understand.

Recent patches that I've submitted were intended as a start to removing 
some of this cruft and I had intended to send more patches after they 
were accepted.  I figured that it was better to do it as a number of 
small changes rather than one big one.  Should I continue?

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