public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Andrea Arcangeli <andrea@suse.de>
Cc: john stultz <johnstul@us.ibm.com>,
	lkml <linux-kernel@vger.kernel.org>, Andi Kleen <ak@suse.de>,
	Ulrich Drepper <drepper@redhat.com>,
	Chris McDermott <lcm@us.ibm.com>,
	Wim Coekaerts <wim.coekaerts@oracle.com>,
	Joel Becker <Joel.Becker@oracle.com>,
	"Martin J. Bligh" <mbligh@aracnet.com>
Subject: Re: [RFC][PATCH] linux-2.6.2_vsyscall-gtod_B2.patch
Date: Sat, 7 Feb 2004 03:18:40 +0000	[thread overview]
Message-ID: <20040207031840.GL12503@mail.shareable.org> (raw)
In-Reply-To: <20040206040123.GN31926@dualathlon.random>

Andrea Arcangeli wrote:
> On Thu, Feb 05, 2004 at 07:10:46PM -0800, john stultz wrote:
> > @@ -6,6 +9,8 @@
> >  	.globl __kernel_vsyscall
> >  	.type __kernel_vsyscall,@function
> >  __kernel_vsyscall:
> > +	cmp $__NR_gettimeofday, %eax
> > +	je .Lvgettimeofday
> >  .LSTART_vsyscall:
> 
> this is the sort of slowdown that could be avoided with the fixed
> address.
> 
> ... the worst part is that not
> only it makes gettimeofday slower, it makes _all_ the syscall slower

Andrea, please keep this argument separate from the argument about
varying vdso addresses.

The Glibc method of calling syscalls is already sub-optimal: the two
instructions in the above patch are nothing, time wise, compared with
the segment-prefixed indirect jump in Glibc and the branches which
check for and toggle POSIX asynchronous cancellations.

Other libcs might be more direct about the syscalls, and then it is
nice to imagine the optimal vdso for them.  But other libcs don't have
to enter the vdso at all, they can just copy the initial instructions
of the vdso and optimise away the path not taken (checking at run time
whether they match the current kernel's vdso of course).  Thus an
optimal vdso isn't strictly required for those of us who are into
hard core binary optimisation.

-- Jamie

      parent reply	other threads:[~2004-02-07  3:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-06  3:10 [RFC][PATCH] linux-2.6.2_vsyscall-gtod_B2.patch john stultz
2004-02-06  4:01 ` Andrea Arcangeli
2004-02-06  9:28   ` Ulrich Drepper
2004-02-06 15:54     ` Andrea Arcangeli
2004-02-07  3:18   ` Jamie Lokier [this message]

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=20040207031840.GL12503@mail.shareable.org \
    --to=jamie@shareable.org \
    --cc=Joel.Becker@oracle.com \
    --cc=ak@suse.de \
    --cc=andrea@suse.de \
    --cc=drepper@redhat.com \
    --cc=johnstul@us.ibm.com \
    --cc=lcm@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@aracnet.com \
    --cc=wim.coekaerts@oracle.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