From: Keith Owens <kaos@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: ia64 printk_clock()
Date: Sat, 04 Feb 2006 00:16:09 +0000 [thread overview]
Message-ID: <15306.1139012169@ocs3> (raw)
In-Reply-To: <20060202204422.GA27082@sgi.com>
"Luck, Tony" (on Fri, 3 Feb 2006 10:43:08 -0800) wrote:
>> Now that I read the whole thread, how about remove pining DTR
>> requirement for per-cpu data? In alt_dtlb_miss, we can just
>> detect whether ifa is per_cpu address and read ar.k3 to get the
>> physical address, then insert a TC. That will free up a tlb
>> entry for application to use.
>
>What will you do when someone accesses per-cpu area before ar.k3
>has been initialized (the bug that we are trying to fix here)?
>
>This would add some extra code to the Alt-DTLB handler. Could
>you hide all/most of the extra latency?
>
>Are there any correctness issues? Any place where we access a
>per-cpu variable where we absolutely cannot take an Alt-DTLB fault?
mca_asm.S, GET_IA64_MCA_DATA(). ia64_mca_data is per cpu and is
accessed right from the start of the MCA/INIT handlers, with psr.i,
psr.ic both 0.
next prev parent reply other threads:[~2006-02-04 0:16 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-02 20:44 ia64 printk_clock() Jack Steiner
2006-02-02 21:22 ` Dean Roe
2006-02-02 21:46 ` Luck, Tony
2006-02-02 21:50 ` Jack Steiner
2006-02-02 22:29 ` Luck, Tony
2006-02-02 22:52 ` Chen, Kenneth W
2006-02-03 17:43 ` Chen, Kenneth W
2006-02-03 18:04 ` Luck, Tony
2006-02-03 18:30 ` Chen, Kenneth W
2006-02-03 18:43 ` Luck, Tony
2006-02-03 18:55 ` Chen, Kenneth W
2006-02-04 0:16 ` Keith Owens [this message]
2006-02-04 0:28 ` Chen, Kenneth W
2006-02-04 0:32 ` Luck, Tony
2006-02-04 0:36 ` Keith Owens
2006-02-06 18:14 ` Luck, Tony
2006-02-06 18:34 ` Chen, Kenneth W
2006-02-06 20:40 ` Magenheimer, Dan (HP Labs Fort Collins)
2006-02-06 21:37 ` Chen, Kenneth W
2006-02-07 11:11 ` Jes Sorensen
2006-02-08 0:05 ` Luck, Tony
2006-02-08 6:29 ` Jes Sorensen
2006-02-08 18:18 ` 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=15306.1139012169@ocs3 \
--to=kaos@sgi.com \
--cc=linux-ia64@vger.kernel.org \
/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