lkml.org 
[lkml]   [2006]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: -mm merge plans for 2.6.20
Hi,

On Wed, 6 Dec 2006, Ingo Molnar wrote:

> * Roman Zippel <zippel@linux-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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-12-06 15:35    [W:0.126 / U:1.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site