All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: John Stultz <john.stultz@linaro.org>
Cc: lkml <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Richard Cochran <richardcochran@gmail.com>
Subject: Re: [PATCH 4/9] time: Update timekeeper structure using a local shadow
Date: Fri, 2 Mar 2012 09:07:38 +0100	[thread overview]
Message-ID: <20120302080738.GA17890@elte.hu> (raw)
In-Reply-To: <1330674796.2361.36.camel@work-vm>


* John Stultz <john.stultz@linaro.org> wrote:

> On Fri, 2012-03-02 at 08:38 +0100, Ingo Molnar wrote:
> > * John Stultz <john.stultz@linaro.org> wrote:
> > 
> > > diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> > > index f9ee96c..09460c1 100644
> > > --- a/kernel/time/timekeeping.c
> > > +++ b/kernel/time/timekeeping.c
> > > @@ -74,6 +74,7 @@ struct timekeeper {
> > >  };
> > >  
> > >  static struct timekeeper timekeeper;
> > > +static struct timekeeper shadow_tk;
> > 
> > Sigh.
> > 
> > As I said it in the first round of review, it's fundamentally 
> > wrong to copy live fields like locks or the clocksource pointer 
> > around.
> 
> So I actually removed the locks out from the timekeeper 
> structure to try to address this concern.

The ->clock pointer is unused as well AFAICS [we pass in 
'offset'] - and that together with the lock is already two 
fields. It's 8 bytes copied back and forth unnecessarily, 
amongst other things.

But yes, moving those two fields out is an equivalent solution 
too - although I do agree with the whole clean-up direction of 
going away from standalone global variables and collecting those 
fields into a single structure. It's your call which one you 
prefer - but mixing the two types does not look clean to me.

> > It's doubly wrong to do it in a global variable that no-one 
> > else but the copying function (update_wall_time()) is 
> > supposed to access.
> > 
> > There are over a dozen fields in 'struct timekeeper' - 
> > exactly which ones of them are used on this private copy, as 
> > update_wall_time() does the cycle accumulation and calls 
> > down into timkeeping_adjust()?
> 
> Just about all of timekeeper state is used and modified in the 
> update_wall_time.
> 
> > The right solution would be to separate timekeeping time state 
> > from global state:
> > 
> > struct timekeeper {
> > 	spinlock_t		lock;
> > 
> > 	struct time_state	time_state;
> > };
> > 
> > And then standardize the time calculation code on passing around 
> > not 'struct timekeeper *' but 'struct time_state *' ! Then you 
> > can have a local shadow copy of the global state:
> > 
> > 	struct time_state time_state_copy;
> > 
> > and copy it from the global one and then pass it down to 
> > calculation functions.
> > 
> > This also gives the freedom to add other global state fields 
> > beyond the lock. (Right now the lock appears to be the only 
> > global state field - there might be more.)
> 
> So, just to be clear, you want me to push basically everything 
> in the timekeeper structure, except the lock (which would be 
> re-added), into a time_state sub-structure?

Moving the lock and any other field not used internally out of 
it is fine as well - plus not using a global shadow_copy but 
making it local to update_wall_time().

Thanks,

	Ingo

  reply	other threads:[~2012-03-02  8:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-02  7:12 [PATCH 0/9] Reduce timekeeping lock hold time v2 John Stultz
2012-03-02  7:12 ` [PATCH 1/9] time: Condense timekeeper.xtime into xtime_sec John Stultz
2012-03-02 21:13   ` Christoph Lameter
2012-03-03  5:54     ` Richard Cochran
2012-03-02  7:12 ` [PATCH 2/9] time: Rework timekeeping functions to take timekeeper ptr as argument John Stultz
2012-03-02  7:12 ` [PATCH 3/9] time: Split timekeeper lock into separate reader/writer locks John Stultz
2012-03-02  7:12 ` [PATCH 4/9] time: Update timekeeper structure using a local shadow John Stultz
2012-03-02  7:38   ` Ingo Molnar
2012-03-02  7:53     ` John Stultz
2012-03-02  8:07       ` Ingo Molnar [this message]
2012-03-02  7:12 ` [PATCH 5/9] time: Shadow cycle_last in timekeeper structure John Stultz
2012-03-02  7:12 ` [PATCH 6/9] time: Reduce timekeeper read lock hold time John Stultz
2012-03-02  7:12 ` [PATCH 7/9] time: Convert the timekeeper's wlock to a raw_spin_lock John Stultz
2012-03-02  7:12 ` [PATCH 8/9] time: Whitespace cleanups per Ingo's requests John Stultz
2012-03-02  7:12 ` [PATCH 9/9] time: Explicitly use u32 instead of int for shift values 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=20120302080738.GA17890@elte.hu \
    --to=mingo@elte.hu \
    --cc=eric.dumazet@gmail.com \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=richardcochran@gmail.com \
    --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.