public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Suleiman Souhlal <ssouhlal@FreeBSD.org>
To: Andi Kleen <ak@suse.de>
Cc: Linux Kernel ML <linux-kernel@vger.kernel.org>,
	vojtech@suse.cz, Jiri Bohac <jbohac@suse.cz>
Subject: Re: [PATCH 1/2] Make the TSC safe to be used by gettimeofday().
Date: Mon, 13 Nov 2006 19:54:00 -0800	[thread overview]
Message-ID: <45593DD8.80301@FreeBSD.org> (raw)
In-Reply-To: <200611140344.00407.ak@suse.de>

Andi Kleen wrote:
>>Because CPUID returns the APIC ID, and I was under the impression that 
>>the cpu numbers
>>smp_processor_id() were dynamically allocated and didn't necessarily 
>>match the
>>APIC ID.
> 
> 
> Correct, but one can use a mapping table.
> 
>>Yes, it's only needed on HLT and cpufreq change.
>>The code here is to force a "resynch" with the HPET if we've done a HLT. 
>>  It has to be done before we switch to any userland thread that might 
>>use the per-cpu vxtime. switch_to() seemed like the most natural place 
>>to put this.
> 
> 
> I don't think so. The natural place after HLT is in the idle loop or 
> better in idle notifiers[1] and after  cpufreq is in the appropiate cpufreq 
> notifiers.
>  
> 
> [1] unfortunately they are still subtly broken in .19, but will be fixed
> in .20

I initially had it after the HLT in the idle loop, but realized there 
would be a small race: We could get switched away from the idle thread 
after the HLT but before doing the resynch.

It seems like idle notifiers would do the trick, except that they don't 
appear to include the id of the CPU that went/exited from idle.

Do you want me to also send a patch that addresses this?

>>A cow-orker suggested that we use SIDT and encode the CPU number in the 
>>limit of the IDT, which should be even faster than LSL.
> 
> 
> Possible yes. Did you time it?
 >
> But then we would make the IDT variable length in memory? While
> the CPUs probably won't care some Hypervisors seem to be picky
> about these limits. LSL still seems somewhat safer.

Does the LSL from the magic GDT entry return the APIC ID or the 
smp_processor_id? If it's the latter, I can avoid using the 
smp_processor_id->apic id table completely.

> 
>>I couldn't figure out how to tell if a context switch has happened from 
>>userland. I tried putting a per-cpu context switch count, but I couldn't 
>>figure out how to get it atomically along with the CPU number..
> 
> 
> It's tricky. That is why we asked for RDTSCP.

Another way I could fix this would be to just touch the seqlock, in 
switch_to(), if we happen to be in vgettimeofday. Would this be acceptable?

-- Suleiman

  parent reply	other threads:[~2006-11-14  3:54 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-14  1:06 [PATCH 0/2] Make the TSC safe to be used by gettimeofday() Suleiman Souhlal
2006-11-14  1:08 ` [PATCH 1/2] " Suleiman Souhlal
2006-11-14  2:05   ` Andi Kleen
2006-11-14  2:25     ` Suleiman Souhlal
2006-11-14  2:44       ` Andi Kleen
2006-11-14  3:35         ` dean gaudet
2006-11-14  4:22           ` dean gaudet
2006-11-14  3:54         ` Suleiman Souhlal [this message]
2006-11-14 11:12           ` Andi Kleen
2006-11-14  1:09 ` [PATCH 2/2] Introduce a vmonotonic_clock() vsyscall Suleiman Souhlal
2006-11-14  1:50 ` [PATCH 0/2] Make the TSC safe to be used by gettimeofday() Andi Kleen
2006-11-14  2:06   ` Suleiman Souhlal
2006-11-14 11:10     ` [PATCH 0/2] Make the TSC safe to be used by gettimeofday() II Andi Kleen
2006-11-14 12:30     ` [PATCH 0/2] Make the TSC safe to be used by gettimeofday() Shem Multinymous
2006-11-14 17:06       ` Suleiman Souhlal
2006-11-14 18:30         ` Andi Kleen
2006-11-14 21:28     ` Christoph Lameter
2006-11-14  7:42   ` Arjan van de Ven

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=45593DD8.80301@FreeBSD.org \
    --to=ssouhlal@freebsd.org \
    --cc=ak@suse.de \
    --cc=jbohac@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vojtech@suse.cz \
    /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