From: Andi Kleen <ak@suse.de>
To: Elladan <elladan@eskimo.com>
Cc: Andi Kleen <ak@suse.de>, Andi Kleen <ak@muc.de>,
Andrea Arcangeli <andrea@suse.de>, Jeff Dike <jdike@karaya.com>,
john stultz <johnstul@us.ibm.com>,
lkml <linux-kernel@vger.kernel.org>,
george anzinger <george@mvista.com>,
Stephen Hemminger <shemminger@osdl.org>,
discuss@x86-64.org, aj@suse.de
Subject: Re: [discuss] Re: [PATCH] linux-2.5.43_vsyscall_A0
Date: Sun, 20 Oct 2002 13:20:41 +0200 [thread overview]
Message-ID: <20021020132041.A24024@wotan.suse.de> (raw)
In-Reply-To: <20021020105841.GA1024@eskimo.com>
On Sun, Oct 20, 2002 at 03:58:41AM -0700, Elladan wrote:
> Not really any more tricky than turning it off globally with a flag.
> It's just more expensive, because you have to propagate the flag into
> vsyscall space on the context switch. In the per-process case,
> self-modifying code would be a less non-viable approach than it is
> globally.
Umm, you forgot about SMP. Modifying it on context switch would require
per CPU mappings and vsyscall pages. Currently the kernel page tables
are shared globally, changing them to be CPU local would be somewhat
involved. While it would be doable as long as x86-64 is limited to three
level page tables for user space it would be a major pain as soon
as four level page tables were supported. In this case multiple threads
sharing the same mm but running on multiple CPUs couldn't share the same
page table anymore, and changing that would make threading significantly
more complicated. On i386 this problem is always there.
Also the context switch is a very critical path, we don't want to add
random junk like this in there.
> Well, self modifying code certainly looked like what Andrea was talking
> about, to avoid the branch overhead on the userspace gettimeofday()
> call.
A test+branch here is completely lost in the noise, not even
worth thinking about.
> It seems that to fix this with proper data-hiding, it would really need
> to be possible to set the vsyscall pages as invalid for the UML process
> (so it could manually emulate the vsyscall), which would then either
> require expensive contex-switching costs to make it a per-process flag,
> or we're back to global self-modifying-code fixups.
I have no problems at all with a system global flag. After all vsyscalls
are just an optimization. When you use UML you can't use that optimization,
very simple. It's similar to other circumstances that have an impact
on the whole system, e.g. when you use floating point in any process
then the context switch becomes slower for everybody. Not a big deal.
-Andi
next prev parent reply other threads:[~2002-10-20 11:14 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-18 22:57 [PATCH] linux-2.5.43_vsyscall_A0 john stultz
2002-10-18 22:58 ` [EXAMPLE CODE] linux-2.5.43_vsyscall_A0 john stultz
2002-10-19 3:52 ` [PATCH] linux-2.5.43_vsyscall_A0 Jeff Dike
2002-10-19 3:10 ` Andi Kleen
2002-10-19 4:49 ` Jeff Dike
2002-10-19 4:02 ` Andi Kleen
2002-10-19 4:16 ` Andrea Arcangeli
2002-10-20 2:59 ` Andi Kleen
2002-10-20 6:44 ` Elladan
2002-10-20 9:27 ` [discuss] " Andi Kleen
2002-10-20 10:58 ` Elladan
2002-10-20 11:20 ` Andi Kleen [this message]
2002-10-20 14:51 ` Andrea Arcangeli
2002-10-21 16:49 ` george anzinger
2002-10-20 13:19 ` Andreas Jaeger
2002-10-20 14:59 ` Andrea Arcangeli
2002-10-19 4:10 ` Andrea Arcangeli
2002-10-19 4:45 ` Andi Kleen
2002-10-19 5:01 ` Andrea Arcangeli
2002-10-19 23:43 ` Jeff Dike
2002-10-20 0:15 ` Andrea Arcangeli
2002-10-20 2:03 ` Jeff Dike
2002-10-20 2:33 ` Andrea Arcangeli
2002-10-22 5:07 ` Jeff Dike
2002-10-22 4:15 ` Andi Kleen
2002-10-22 4:29 ` Andrew Morton
2002-10-22 9:39 ` Alan Cox
2002-10-22 16:12 ` Andrew Morton
2002-10-22 5:08 ` Andrea Arcangeli
2002-10-22 5:27 ` Andrea Arcangeli
2002-10-22 7:24 ` Elladan
2002-10-22 7:40 ` Andrea Arcangeli
2002-10-23 5:12 ` Elladan
2002-10-23 5:43 ` Elladan
2002-10-23 17:51 ` Gerrit Huizenga
2002-10-21 15:43 ` Stephen Hemminger
2002-10-21 16:26 ` Andi Kleen
2002-10-21 17:10 ` john stultz
2002-10-19 19:14 ` Bill Davidsen
2002-10-20 1:50 ` Rik van Riel
2002-10-20 2:56 ` Andi Kleen
2002-10-24 11:24 ` Pavel Machek
2002-10-24 11:24 ` Pavel Machek
2002-10-19 22:36 ` Ton Hospel
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=20021020132041.A24024@wotan.suse.de \
--to=ak@suse.de \
--cc=aj@suse.de \
--cc=ak@muc.de \
--cc=andrea@suse.de \
--cc=discuss@x86-64.org \
--cc=elladan@eskimo.com \
--cc=george@mvista.com \
--cc=jdike@karaya.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=shemminger@osdl.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 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.