From: Andrea Arcangeli <andrea@suse.de>
To: Andi Kleen <ak@muc.de>
Cc: Jeff Dike <jdike@karaya.com>, john stultz <johnstul@us.ibm.com>,
Linus Torvalds <torvalds@transmeta.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: [PATCH] linux-2.5.43_vsyscall_A0
Date: Sun, 20 Oct 2002 16:51:49 +0200 [thread overview]
Message-ID: <20021020145149.GT23930@dualathlon.random> (raw)
In-Reply-To: <20021020025914.GB15342@averell>
On Sun, Oct 20, 2002 at 04:59:14AM +0200, Andi Kleen wrote:
> On Sat, Oct 19, 2002 at 06:16:59AM +0200, Andrea Arcangeli wrote:
> > see my last email. And I think he needed it as an additional syscall
> > after execve that he could trap and revirtualize with ptrace as usual
> > and that would return variable addresses of pointer to functions (that
> > would be revirtualized inside the uml kernel of course), not an ELF
> > information that should be valid for both UML and host kernel.
>
> Implementing it per process is tricky. How do you access the per process
> state in the vsyscall area ? To do it properly you would need one dedicated
you don't need to access the per-process state of course.
the code will do:
switch_to() {
[..]
if (prev->vsyscall_disabled != next->vsyscall_disabled) {
set the right fixmap page and invlpg
}
[..]
}
the vsyscall code itself will not need to know anything about the
current->vsyscall_disabled. The only overhead is such above branch.
> page per mm_struct that is mapped in there. But it could not be in the
> normal vsyscall area (otherwise you couldn't share the kernel pagetables
> anymore), but somewhere else in the address space.
>
> I think a global sysctl that just modifies the global vsyscall pages is more
> suitable here. It avoids the overhead of needing a per process page.
I don't see the need of a per-process page. We only need a per-cpu
first level pagetable at the very end of the address space, but that's
not a problem at all, it's one more page _per_cpu_ only (not per task).
It's much less overhead of per-cpu keventd etc...
> I see no real need anyways to do it per process. When you have one process
> that cannot deal with vsyscalls the whole system will get a bit slower,
> but the slowdown shouldn't be noticeable anyways. If you run your highend
> database which does thousands of gettimeofday each second just don't set
> the sysctl.
yep. Having the per-task switch was only a way to make the host system
more efficient for the 1% uml users that has to fake the time and that
cannot live with the max possible perormance of having uml running with
the system time in sync with the host. the per-task switch is meant to
give uml the possibility of being fully revirtualized without hurting
the host too much, in the unlikely case you need it.
Andrea
next prev parent reply other threads:[~2002-10-20 14:45 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
2002-10-20 14:51 ` Andrea Arcangeli [this message]
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=20021020145149.GT23930@dualathlon.random \
--to=andrea@suse.de \
--cc=aj@suse.de \
--cc=ak@muc.de \
--cc=discuss@x86-64.org \
--cc=george@mvista.com \
--cc=jdike@karaya.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=shemminger@osdl.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox