From: Andi Kleen <ak@suse.de>
To: Ingo Molnar <mingo@elte.hu>
Cc: john stultz <johnstul@us.ibm.com>,
Darren Hart <dvhltc@us.ibm.com>,
Nishanth Aravamudan <nacc@us.ibm.com>,
Frank Sorenson <frank@tuxrocks.com>,
George Anzinger <george@mvista.com>,
Roman Zippel <zippel@linux-m68k.org>,
Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/13] Time: Generic Timeofday Subsystem (v B10)
Date: Sun, 13 Nov 2005 11:53:24 +0100 [thread overview]
Message-ID: <200511131153.25978.ak@suse.de> (raw)
In-Reply-To: <20051113073228.GA31468@elte.hu>
On Sunday 13 November 2005 08:32, Ingo Molnar wrote:
> there are 3 "generic" components needed right now to clean up all time
> related stuff: GTOD, ktimers and clockevents. [you know the first two,
> and clockevents is new code from Thomas Gleixner that generalizes timer
> interrupts and introduces one compact notion for 'clock chips'.]
Both noidletick and the per cpu gettimeofday change significantly
how timer interrupts work. I hope your generalizations will be still
compatible to that. It's a bit dangerous to generalize
before things have their final shape.
Also vsyscalls make it all more difficult, because they don't map
very well to any kind of "timer drivers".
> what is the point? Ontop of these, a previously difficult feature, High
> Resolution Timers became _massively_ simpler. All of these patches exist
> together in the -rt tree, so it's not handwaving. The same will be the
> case for idle ticks / dynamic ticks [we started with HRT because it is
> so much harder than idle ticks]. So i do agree with you that GTOD needs
> more work, but it also makes time related features all that much easier.
>
> right now it's GTOD that needs the most work before it can be merged
> upstream, so you picked the right one to criticise :-)
My point was basically that there is a lot of feature work going on
on x86-64 in this area, and that has priority over any "cleanups" like this
from my side. If it has settled again later maybe it can be generalized,
or maybe not. I will only do it if it truly makes the code cleaner in the end,
just lots of indirect pointers by itself isn't necessarily something
that does this.
-Andi
next prev parent reply other threads:[~2005-11-13 11:09 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-12 4:48 [PATCH 0/13] Time: Generic Timeofday Subsystem (v B10) john stultz
2005-11-12 4:48 ` [PATCH 1/13] Time: Reduced NTP rework (part 1) john stultz
2005-11-12 4:49 ` [PATCH 2/13] Time: Reduced NTP Rework (part 2) john stultz
2005-11-12 4:49 ` [PATCH 3/13] Time: Clocksource Infrastructure john stultz
2005-11-12 4:49 ` [PATCH 4/13] Time: Generic Timekeeping Infrastructure john stultz
2005-11-12 4:49 ` [PATCH 5/13] Time: i386 Conversion - part 1: Move timer_pit.c to i8253.c john stultz
2005-11-12 4:49 ` [PATCH 6/13] Time: i386 Conversion - part 2: Move timer_tsc.c to tsc.c john stultz
2005-11-12 4:49 ` [PATCH 7/13] Time: i386 Conversion - part 3: Rework TSC Support john stultz
2005-11-12 4:49 ` [PATCH 8/13] Time: i386 Conversion - part 4: ACPI PM variable renaming john stultz
2005-11-12 4:49 ` [PATCH 9/13] Time: i386 Conversion - part 5: Enable Generic Timekeeping john stultz
2005-11-12 4:49 ` [PATCH 10/13] Time: i386 Conversion - part 6: Remove Old Code john stultz
2005-11-12 4:50 ` [PATCH 11/13] Time: x86-64 Conversion to Generic Timekeeping john stultz
2005-11-12 4:50 ` [PATCH 12/13] Time: i386/x86-64 Clocksource Drivers john stultz
2005-11-12 4:50 ` [PATCH 13/13] Time: Generic Timekeeping Paraniod Debug Patch john stultz
2005-11-13 1:24 ` [PATCH 0/13] Time: Generic Timeofday Subsystem (v B10) Andi Kleen
2005-11-13 2:34 ` john stultz
2005-11-13 7:32 ` Ingo Molnar
2005-11-13 10:53 ` Andi Kleen [this message]
2005-11-14 17:41 ` john stultz
2005-11-14 18:23 ` Ingo Molnar
2005-11-14 21:22 ` Frank Sorenson
2005-11-14 21:38 ` john stultz
2005-11-14 21:53 ` Frank Sorenson
2005-11-14 22:02 ` john stultz
2005-11-14 23:07 ` Frank Sorenson
2005-11-14 23:25 ` john stultz
2005-11-15 5:04 ` Frank Sorenson
2005-11-15 19:53 ` john stultz
2005-11-15 20:53 ` Ingo Molnar
2005-11-15 21:04 ` john stultz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200511131153.25978.ak@suse.de \
--to=ak@suse.de \
--cc=dvhltc@us.ibm.com \
--cc=frank@tuxrocks.com \
--cc=george@mvista.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nacc@us.ibm.com \
--cc=tglx@linutronix.de \
--cc=ulrich.windl@rz.uni-regensburg.de \
--cc=zippel@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.