public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: tony.luck@intel.com
Cc: nacc@us.ibm.com, mingo@elte.hu, linux-ia64@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [BISECTION RESULT] sched: revert cpu_clock to
Date: Mon, 04 Aug 2008 22:14:48 +0000	[thread overview]
Message-ID: <20080804.151448.190011603.davem@davemloft.net> (raw)
In-Reply-To: <57C9024A16AD2D4C97DC78E552063EA308329139@orsmsx505.amr.corp.intel.com>

From: "Luck, Tony" <tony.luck@intel.com>
Date: Mon, 4 Aug 2008 15:10:40 -0700

> > Can you guys on IA64 possibly set ar.k3 simply to zero or to some
> > other similar value which cancels out the per-cpu computation?
> >
> > That's what sparc64 and other platforms do.
> 
> In cpu_init() we set ar.k3 to the base physical address of the percpu
> area.  The alt-dtlb miss handler uses this register to set up a
> TLB mapping from virtual address 0xffffffffffff0000 to this physical
> address.
> 
> This means that most per-cpu accesses are very cheap (as the compiler
> can use a small -ve offset from register r0 to load the virtual
> address).
> 
> Accessing ar.k3 is a bit slow ... so making the per-cpu code
> use that on every access to a per-cpu variable would be unpleasant.

I understand that you use TLB mappings.

What I'm suggesting is to very early on set ar.k3 to something which
makes accesses go through the __per_cpu image copy in the main kernel
image.

You could even set up a dummy TLB mapping during this early boot
period.

Otherwise it's just cleverness that is unique to IA64 and is going to
constantly run into issues like this.  An alternative is to implement
your own sched_clock() et al. where you can adhere to whatever special
rules your platform may have.

  reply	other threads:[~2008-08-04 22:14 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-04 19:46 [BISECTION RESULT] sched: revert cpu_clock to Nishanth Aravamudan
2008-08-04 20:37 ` Luck, Tony
2008-08-04 22:00   ` Luck, Tony
2008-08-04 22:02     ` David Miller
2008-08-04 22:10       ` Luck, Tony
2008-08-04 22:14         ` David Miller [this message]
2008-08-04 22:22           ` Luck, Tony
2008-08-04 22:41             ` Luck, Tony
2008-08-04 22:45     ` Nishanth Aravamudan
2008-08-04 22:53       ` Luck, Tony
2008-08-04 23:30         ` Nishanth Aravamudan
2008-08-05  8:56 ` Peter Zijlstra
2008-08-05 14:59   ` Luck, Tony
2008-08-05 17:34   ` Nishanth Aravamudan
2008-08-13  0:37 ` Luck, Tony
2008-08-13 16:25   ` Ingo Molnar
2008-08-13 19:29     ` Nishanth Aravamudan
2008-08-13 20:11       ` Luck, Tony
2008-08-19 22:19         ` Nishanth Aravamudan
2008-08-19 22:34           ` Luck, Tony

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=20080804.151448.190011603.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nacc@us.ibm.com \
    --cc=tony.luck@intel.com \
    /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