public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Richard Kennedy <richard@rsk.demon.co.uk>
To: John Stultz <johnstul@us.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	lkml <linux-kernel@vger.kernel.org>
Subject: [PATCH] kernel/timekeeping:  move xtime_cache to be in the same cache line as the lock
Date: Thu, 21 Jan 2010 15:39:21 +0000	[thread overview]
Message-ID: <1264088361.2082.45.camel@localhost> (raw)

move xtime_cache to be in the same cache line as the lock
    
allowing current_kernel_time() to access only one cache line

when running fio write tests on a 2 core machine, on some of the runs
'perf record -e cache_misses' shows current_kernel_time near the top of
the list of cache_misses with 5.5%.
On the other runs it's down at 0.05% so I'm assuming that the difference
is just down to which core the test client get run on.

This patch moves the xtime_cache variable near to the lock so that it
only need to access one cache line.
With this applied it drops the current_kernel_time cache_misses in the
slow case to 4.5%

Signed-off-by: Richard Kennedy <richard@rsk.demon.co.uk>


---
patch against v2.6.33-rc4
compiled & tested on AMD64X2 x86_64


BTW on 64 bit timespec is a 16 byte structure so the aligned 16 doesn't
do much, and on 32bit timepec is 8bytes so this just seems to spread
these variables across more cache lines than necessary. Any ideas what
this is here for?

regards
Richard  



diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 7faaa32..657e861 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -137,6 +137,7 @@ static inline s64 timekeeping_get_ns_raw(void)
  */
 __cacheline_aligned_in_smp DEFINE_SEQLOCK(xtime_lock);
 
+static struct timespec xtime_cache __attribute__ ((aligned (16)));
 
 /*
  * The current time
@@ -165,7 +166,6 @@ struct timespec raw_time;
 /* flag for if timekeeping is suspended */
 int __read_mostly timekeeping_suspended;
 
-static struct timespec xtime_cache __attribute__ ((aligned (16)));
 void update_xtime_cache(u64 nsec)
 {
 	xtime_cache = xtime;



             reply	other threads:[~2010-01-21 15:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-21 15:39 Richard Kennedy [this message]
2010-01-21 17:19 ` [PATCH] kernel/timekeeping: move xtime_cache to be in the same cache line as the lock john stultz
2010-01-22 11:10   ` Richard Kennedy
2010-01-26 23:28 ` Andrew Morton
2010-01-27 12:10   ` Richard Kennedy
2010-01-28 20:16     ` 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=1264088361.2082.45.camel@localhost \
    --to=richard@rsk.demon.co.uk \
    --cc=akpm@linux-foundation.org \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=schwidefsky@de.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox