linux-kernel - Re: -mm merge plans for 2.6.20

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]

Message-ID: <20061206165842.GA17755@elte.hu>
Date:	Wed, 6 Dec 2006 17:58:42 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Roman Zippel <zippel@...ux-m68k.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org
Subject: Re: -mm merge plans for 2.6.20

* Roman Zippel <zippel@...ux-m68k.org> wrote:

> > > > > [...] one obvious user would be the scheduler, [...]
> > 
> > but that is not a refutation of what Thomas said, at all. You say 
> > that the scheduler /could/ use such a facility. What Thomas said was 
> > that /there are no current users of such a facility/. It is a really 
> > simple (and unconditionally true) observation from Thomas. Yes, we 
> > could change other kernel code not directly related to high-res 
> > timers, but we chose not to.
> 
> I didn't say "/could/", the scheduler _needs_ such a facility. [...]

i disagree that the scheduler unconditionally 'needs' such a facility. 
The scheduler clock is pretty special and has other requirements and 
constraints than generic timekeeping clocks. It /might/ and /could/ 
utilize such an infrastructure, but it's not at all clear that it 
'needs' such a facility.

in any case, i very much entertain the possibility of more synergy in 
this space, but it's far from obvious and it's definitely not 
unconditionally 'necessary'. The scheduler and profiling code certainly 
worked for 15 years without such synergy. What we concentrated on in 
this patchset is high-resolution timers and dynticks, not scheduler or 
profiler clock cleanups. We cleaned up everything that we impacted 
directly, but we also tried to limit the scope of the changes wherever 
possible.

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