All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ulrich Drepper <drepper@redhat.com>,
	David Miller <davem@davemloft.net>,
	linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	mingo@elte.hu, tglx@linutronix.de
Subject: Re: [PATCHv4 5/6] Allow setting O_NONBLOCK flag for new sockets
Date: Mon, 26 Nov 2007 18:38:17 -0800	[thread overview]
Message-ID: <474B8319.8000606@zytor.com> (raw)
In-Reply-To: <alpine.LFD.0.9999.0711261801390.5869@woody.linux-foundation.org>

Linus Torvalds wrote:
> 
>> The 6-word limit is a red herring.  There is at least two ways to deal with it
>> (and this doesn't mean wiping the legacy stuff we already have):
>>
>> - Let each architecture pick a calling convention and redefine the
>> architecture-independent bits to take an arbitrary number of arguments.  This
>> is a one-time panarchitectural change.
> 
> Not applicable on x86-32.
> 
> The six-word limit is effectively a hardware limit there. Once it goes 
> past that limit, one of the words needs to be a pointer to extended 
> information that is fundamentally slower to access. Happily, only very 
> rare system calls do that (and none of them are of the simple variety 
> where we see a few cycles easily).
> 
> On other architectures, we could more easily just use more registers. But 
> x86-32 is still a big part (bulk) of what matters for most people.
> 

Well, x86-32 and x86-64 are surprisingly similar here, for very 
different reasons (x86-64 is because there are only seven clobbered 
registers that aren't destroyed by the syscall instruction itself.)

However, on both of these we could make the user-space side cheaper, by 
making sure that we don't have to do additional copies in user space. 
For both these architectures, anything more than 3 parameters (i386) or 
6 parameters (x86-64) will be already in memory on the stack, so if we 
can use that image as-is then we at least save the intra-user-space copy 
that goes along with it.

x86-64 requires some minor thought, since the obvious way of doing it 
(using arg register 6 to push in a pointer) would end up with a 
discontiguous frame.  One can do it with something like this, although 
it's not clear to me it is a win at all (the more obvious sequence using 
XCHG isn't usable since XCHG locks unconditionally):

	pop	%r10			# Return address
	push	%r9			# Argument 6
	movq	%rsp, %r11
	push	%r10
	movq	%rcx, %r10
	syscall
	cmpq	$-4095, %rax
	jae	...
	pop	%r10
	pop	%r9
	push	%r10
	retq

The number of registers do vary, obviously, with s390 being the smallest 
number (5).

> Immediately when you do anything but registers, it is much *much* more 
> costly. The "get_user()" and "copy_from_user()" stuff is not exactly slow, 
> but it's quite noticeable overhead for simple system calls. It gets worse 
> if this all is described by some indirect table setup.

True, of course, although we're talking here about different ways to 
pull arguments out of userspace memory; *definitely* agreed with that we 
don't want to have any additional indirection necessary.

	-hpa

  reply	other threads:[~2007-11-27  2:39 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-20  6:53 [PATCHv4 5/6] Allow setting O_NONBLOCK flag for new sockets Ulrich Drepper
2007-11-20  7:59 ` David Miller
2007-11-20 16:04   ` Ulrich Drepper
2007-11-20 18:13     ` H. Peter Anvin
2007-11-20 18:24       ` Zach Brown
2007-11-20 19:12         ` H. Peter Anvin
2007-11-20 22:22           ` Ingo Molnar
2007-11-20 22:33             ` Davide Libenzi
2007-11-20 22:42               ` Ingo Molnar
2007-11-20 23:25             ` H. Peter Anvin
2007-11-20 23:41               ` Ingo Molnar
2007-11-20 23:57                 ` H. Peter Anvin
2007-11-26 18:17       ` Linus Torvalds
2007-11-26 18:45         ` Ingo Molnar
2007-11-26 19:07           ` H. Peter Anvin
2007-11-26 19:55             ` Davide Libenzi
2007-11-26 19:20         ` H. Peter Anvin
2007-11-26 23:25           ` Ulrich Drepper
2007-11-27  0:14             ` H. Peter Anvin
2007-11-27  0:42               ` Ulrich Drepper
2007-11-27  1:23                 ` H. Peter Anvin
2007-11-27  2:14           ` Linus Torvalds
2007-11-27  2:38             ` H. Peter Anvin [this message]
2007-11-20 21:48     ` David Miller
2007-11-20 21:55       ` Zach Brown
2007-11-20 22:36         ` David Miller
2007-11-20 17:54   ` Zach Brown

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=474B8319.8000606@zytor.com \
    --to=hpa@zytor.com \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=drepper@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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.