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]

Date:	Wed, 6 Dec 2006 15:33:12 +0100 (CET)
From:	Roman Zippel <zippel@...ux-m68k.org>
To:	Ingo Molnar <mingo@...e.hu>
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

Hi,

On Wed, 6 Dec 2006, Ingo Molnar wrote:

> * 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?

What's the point of this question? Your answer is/was in the "[...]" part.

> Fact: there is no current 
> user of such a facility. What we implemented, high-res timers and 
> dynticks does not need such a facility.

Fact: there _are_ users which need a timer facility (e.g. the scheduler).

> 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.

Maybe the existing code should have been cleaned up first? Unfortunately 
the dynticks feature seems to more appealing than clean code...

> > [...] 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?

Would you please stop these personal attacks?

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

Since this is very important code, it would be rather useful to know 
what's coming and to get to an agreement about the general direction this 
code is taking. This code has to cover a wide range of applications, where 
as you guys are rather focused on realtime applications, which is ok, but 
we need to _carefully_ rethink how time is managed within the kernel, 
instead of randomly poking around in the kernel.

> > [...] 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.

Why do you pick on the NTP code? That's actually one of the places where 
assumptions about HZ are largely gone. NTP state is updated incrementally 
and this won't change, but the update frequency can now be easily 
disconnected from HZ.

bye, Roman
-
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/