From: Vojtech Pavlik <vojtech@suse.cz>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Pavel Machek <pavel@ucw.cz>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
"J.E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
john stultz <johnstul@us.ibm.com>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: Voyager subarchitecture for 2.5.46
Date: Sun, 10 Nov 2002 20:46:20 +0100 [thread overview]
Message-ID: <20021110204620.A15515@ucw.cz> (raw)
In-Reply-To: <Pine.LNX.4.44.0211101050170.9581-100000@home.transmeta.com>; from torvalds@transmeta.com on Sun, Nov 10, 2002 at 10:59:55AM -0800
On Sun, Nov 10, 2002 at 10:59:55AM -0800, Linus Torvalds wrote:
> On Sun, 10 Nov 2002, Pavel Machek wrote:
> >
> > Unfortunately, this means "bye bye vsyscalls for gettimeofday".
>
> Not necessarily. All of the fastpatch and the checking can be done by the
> vsyscall, and if the vsyscall notices that there is a backwards jump in
> time it just gives up and does a real system call. The vsyscall does need
> to figure out the CPU it's running on somehow, but that should be solvable
> - indexing through the thread ID or something.
I'm planning to store the CPU number in the highest bits of the TSC ...
> That said, I suspect that the real issue with vsyscalls is that they don't
> really make much sense. The only system call we've ever found that matters
> at all is gettimeofday(), and the vsyscall implementation there looks like
> a "cool idea, but doesn't really matter (and complicates things a lot)".
It's not complicating things overly. We'd have to go through most of the
hoops anyway if we wanted a fast gettimeofday syscall instead of a
vsyscall.
> The system call overhead tends to scale up very well with CPU speed (the
> one esception being the P4 which just has some internal problems with "int
> 0x80" and slowed down compared to a PIII).
>
> So I would just suggest not spending a lot of effort on it, considering
> the problems it already has.
Agreed. The only problem left I see is the need to have an interrupt of
every CPU from time to time to update the per-cpu time values, and to
synchronize those to the 'global timer interrupt' somehow.
--
Vojtech Pavlik
SuSE Labs
next prev parent reply other threads:[~2002-11-10 19:40 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-05 20:45 Voyager subarchitecture for 2.5.46 J.E.J. Bottomley
2002-11-06 2:31 ` john stultz
2002-11-06 13:43 ` Alan Cox
2002-11-06 21:35 ` john stultz
2002-11-06 15:03 ` J.E.J. Bottomley
2002-11-06 15:38 ` Alan Cox
2002-11-06 16:09 ` Christer Weinigel
2002-11-06 15:45 ` Linus Torvalds
2002-11-06 16:19 ` Alan Cox
2002-11-06 16:12 ` Linus Torvalds
2002-11-06 16:45 ` Alan Cox
2002-11-10 16:30 ` Pavel Machek
2002-11-10 18:59 ` Linus Torvalds
2002-11-10 19:18 ` Pavel Machek
2002-11-10 19:31 ` Linus Torvalds
2002-11-10 19:42 ` Pavel Machek
2002-11-10 19:48 ` Vojtech Pavlik
2002-11-10 20:02 ` Sean Neakums
2002-11-10 20:16 ` Lars Marowsky-Bree
2002-11-10 22:11 ` Alan Cox
2002-11-10 19:46 ` Vojtech Pavlik [this message]
2002-11-11 20:40 ` john stultz
2002-11-11 20:57 ` J.E.J. Bottomley
2002-11-11 21:36 ` William Lee Irwin III
2002-11-11 21:58 ` john stultz
2002-11-11 22:49 ` J.E.J. Bottomley
2002-11-11 23:12 ` john stultz
2002-11-12 12:16 ` Pavel Machek
2002-11-11 22:08 ` Vojtech Pavlik
2002-11-06 20:07 ` john stultz
2002-11-06 22:36 ` H. Peter Anvin
2002-11-06 19:30 ` 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=20021110204620.A15515@ucw.cz \
--to=vojtech@suse.cz \
--cc=James.Bottomley@HansenPartnership.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=torvalds@transmeta.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 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.