All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Stultz <john.stultz@linaro.org>
To: Ingo Molnar <mingo@elte.hu>
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: Thu, 01 Mar 2012 23:53:16 -0800	[thread overview]
Message-ID: <1330674796.2361.36.camel@work-vm> (raw)
In-Reply-To: <20120302073848.GB32401@elte.hu>

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.

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

Sorry for being dense here (its been a long day), but maybe could you
clarify a bit more about the differences you're describing between
time-state and global-state wrt the timekeeper?

thanks
-john


  reply	other threads:[~2012-03-02  7:53 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 [this message]
2012-03-02  8:07       ` Ingo Molnar
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=1330674796.2361.36.camel@work-vm \
    --to=john.stultz@linaro.org \
    --cc=eric.dumazet@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --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.