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: <20061206131155.GA8558@elte.hu>
Date:	Wed, 6 Dec 2006 14:11:55 +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:

> On Wed, 6 Dec 2006, Thomas Gleixner wrote:
> 
> > If I understand it correctly, Roman wants clockevents to be usable 
> > for other things aside hrtimer/dyntick, i.e. let other code request 
> > unused timer event hardware for special purposes. I thought about 
> > that in the originally but I stayed away from it, as there are no 
> > users at the moment and I wanted to avoid the usual "who needs that" 
> > comment.
> 
> Nonsense, [...]

why do you call Thomas' observation nonsense? Fact: there is no current 
user of such a facility. What we implemented, high-res timers and 
dynticks does not need such a facility.

we wholeheartedly agree that such a facility 'would be nice', and 'could 
be used by existing kernel code' but we didnt want to chew too much at a 
time.

> [...] one obvious user would be the scheduler, [...]

But cleaning up the scheduler tick was not our purpose with high-res 
timers nor with dynticks. One of your previous complaints was that the 
patches are too intrusive to be trusted. Now they are too simple?

We'll clean up the scheduler tick and profiling too, but not now.

> [...] the current scheduler tick emulation is rather ugly [...]

i disagree with you and it's pretty low-impact anyway. There's still 
quite many HZ/tick assumptions all around the time code (NTP being one 
example), we'll deal with those via other patches.

	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/