From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: john stultz <johnstul@us.ibm.com>
Cc: Daniel Walker <dwalker@fifo99.com>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC][patch 1/5] move clock source related code to clocksource.c
Date: Thu, 23 Jul 2009 09:53:36 +0200 [thread overview]
Message-ID: <20090723095336.2cb4b1a4@skybase> (raw)
In-Reply-To: <1248308900.7592.36.camel@localhost.localdomain>
On Wed, 22 Jul 2009 17:28:20 -0700
john stultz <johnstul@us.ibm.com> wrote:
> Hey Martin,
> So here's a really quick swipe at breaking apart the clocksource struct
> into a clocksource only portion and a timekeeping portion.
>
> Caveats:
> 1) This doesn't completely build. The core bits do, but there's still a
> few left-over issues (see following caveats). Its just here to give you
> an idea of what I'm thinking about. I'd of course break it up into more
> manageable chunks before submitting it.
>
> 2) Structure names aren't too great right now. Not sure timeclock is
> what I want to use, probably system_time or something. Will find/replace
> before the next revision is sent out.
>
> 3) I still need to unify the clocksource and cyclecounter structures, as
> they're basically redundant now.
>
> 4) I still need to fix the update_vsyscall code (shouldn't be hard, I
> didn't want to run through arch code yet).
>
> 5) The TSC clocksource uses cycles_last to avoid very slight skew issues
> (that otherwise would not be noticed). Not sure how to fix that if we're
> pulling cycles_last (which is purely timekeeping state) out of the
> clocksource. Will have to think of something.
>
>
> Other cleanups still out there in the distant future:
> 1) Once all arches are converted to GENERIC_TIME, we can remove the
> ifdefs, and cleanup a lot of the more complicated xtime struct
> manipulation. It will cleanup update_wall_time() nicely.
>
> 2) I have a logarithmic accumulation patch to update_wall_time that will
> remove the need for xtime_cache to be managed and updated. Just have to
> spend some additional time making sure its bugfree.
>
> 3) Once all arches are converted to using read_persistent_clock(), then
> the arch specific time initialization can be dropped. Removing the
> majority of direct xtime structure accesses.
>
> 4) Then once the remaining direct wall_to_monotonic and xtime accessors
> are moved to timekeeping.c we can make those both static and embed them
> into the core timekeeping structure.
>
>
> But let me know if this patch doesn't achieve most of the cleanup you
> wanted to see.
Cool, I'll have a look. What I can see right away is that a lot of the
changes I tried yesterday are contained in your patch as well.
But your patch is more radical, a lot more is (re-)moved from the
struct clocksource. That mult_orig goes aways is good :-)
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
next prev parent reply other threads:[~2009-07-23 7:53 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-21 19:17 [RFC][patch 0/5] clocksource cleanup / improvement Martin Schwidefsky
2009-07-21 19:17 ` [RFC][patch 1/5] move clock source related code to clocksource.c Martin Schwidefsky
2009-07-21 19:50 ` Daniel Walker
2009-07-21 21:55 ` Martin Schwidefsky
2009-07-21 22:00 ` john stultz
2009-07-22 7:25 ` Martin Schwidefsky
2009-07-22 17:45 ` john stultz
2009-07-23 0:28 ` john stultz
2009-07-23 7:53 ` Martin Schwidefsky [this message]
2009-07-23 10:52 ` Martin Schwidefsky
2009-07-25 0:08 ` john stultz
2009-07-27 11:55 ` Martin Schwidefsky
2009-07-23 7:23 ` Martin Schwidefsky
2009-07-21 19:17 ` [RFC][patch 2/5] cleanup clocksource selection Martin Schwidefsky
2009-07-21 22:07 ` john stultz
2009-07-21 19:17 ` [RFC][patch 3/5] remove clocksource inline functions Martin Schwidefsky
2009-07-21 19:48 ` Daniel Walker
2009-07-21 22:03 ` john stultz
2009-07-22 7:33 ` Martin Schwidefsky
2009-07-21 19:17 ` [RFC][patch 4/5] clocksource_read/clocksource_read_raw " Martin Schwidefsky
2009-07-21 22:01 ` john stultz
2009-07-22 7:29 ` Martin Schwidefsky
2009-07-21 19:17 ` [RFC][patch 5/5] update clocksource with stop_machine Martin Schwidefsky
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=20090723095336.2cb4b1a4@skybase \
--to=schwidefsky@de.ibm.com \
--cc=dwalker@fifo99.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
/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.