All of lore.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/1] Make the TSC safe to be used by gettimeofday().
Date: Tue, 14 Nov 2006 23:14:17 -0800	[thread overview]
Message-ID: <455ABE49.10109@FreeBSD.org> (raw)
In-Reply-To: <200611150542.14239.ak@suse.de>

Andi Kleen wrote:
> On Wednesday 15 November 2006 00:36, Suleiman Souhlal wrote:
> 
>>This is done by a per-cpu vxtime structure that stores the last TSC and HPET
>>values.
>>
>>Whenever we switch to a userland process after a HLT instruction has been
>>executed or after the CPU frequency has changed, we force a new read of the
>>TSC, HPET and xtime so that we know the correct frequency we have to deal
>>with.
>>
>>We also force a resynch once every second, on every CPU.
> 
> 
> Hmm, not sure we want to do it this way. Especially since you
> got unsolved races. But patch review ignoring the 10k foot picture again.
> 

Which unresolved races?
The reason why I do a resynch every CPU is to prevent the HPET timer from
rolling over more than once before reading it again, which could happen
if the CPU doesn't go into HLT for a long time.

>>+
>>+	/*
>>+	 * If we are switching away from a process in vsyscall, touch
>>+	 * the vxtime seq lock so that userland is aware that a context switch
>>+	 * has happened.
>>+	 */
>>+	rip = *(unsigned long *)(prev->rsp0 +
>>+	    offsetof(struct user_regs_struct, rip) - sizeof(struct pt_regs));
>>+	if (unlikely(rip > VSYSCALL_START) && unlikely(rip < VSYSCALL_END)) {
>>+		write_seqlock(&vxtime.vx_seq);
>>+		write_sequnlock(&vxtime.vx_seq);
>>+	}
>>+
> 
> 
> Can't this starve? If a process is unlucky enough (e.g. from 
> lots of interrupts) that it can't go through the vsyscall without at 
> least one context switch it will never finish. Ok maybe it's an 
> unlikely enough livelock, but it still makes me uncomfortable.

I could make it fall back to a full syscall after a certain number of tries.
This, coupled with using a preemption count instead of touching the seq lock
should prevent the livelock (because if we don't touch the seq lock in switch_to
the livelock would not be possible in the full gettimeofday() syscall).
> 
>> 
>>-  .vxtime : AT(VLOAD(.vxtime)) { *(.vxtime) }
>>-  vxtime = VVIRT(.vxtime);
>>-
>>   .vgetcpu_mode : AT(VLOAD(.vgetcpu_mode)) { *(.vgetcpu_mode) }
>>   vgetcpu_mode = VVIRT(.vgetcpu_mode);
>> 
>>@@ -119,6 +116,9 @@ #define VVIRT(x) (ADDR(x) - VVIRT_OFFSET
>>   .vsyscall_2 ADDR(.vsyscall_0) + 2048: AT(VLOAD(.vsyscall_2)) { *(.vsyscall_2) }
>>   .vsyscall_3 ADDR(.vsyscall_0) + 3072: AT(VLOAD(.vsyscall_3)) { *(.vsyscall_3) }
>> 
>>+  .vxtime : AT(VLOAD(.vxtime)) { *(.vxtime) }
>>+  vxtime = VVIRT(.vxtime);
> 
> 
> Why did you move it?

Because otherwise .jiffies (IIRC) collides with .vsyscall_0.

> 
>>+long vgetcpu(unsigned *cpu, unsigned *node, struct getcpu_cache *tcache);
> 
> 
> externs in c code are still forbidden, even if they don't have
> extern


This is just a forward declaration, but I'll get rid of it anyway.

Thanks a lot for the feedback.
I'll try to address these issues and send and a fixed patch.

-- Suleiman


  reply	other threads:[~2006-11-15  7:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-14 23:28 [PATCH 0/1] Try 2: Make the TSC safe to be use by gettimeofday() Suleiman Souhlal
2006-11-14 23:36 ` [PATCH 1/1] Make the TSC safe to be used " Suleiman Souhlal
2006-11-15  4:42   ` Andi Kleen
2006-11-15  7:14     ` Suleiman Souhlal [this message]
2006-11-14 23:39 ` [PATCH 0/1] Try 2: Make the TSC safe to be use " Suleiman Souhlal

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=455ABE49.10109@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 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.