public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Vitaly Mayatskikh <v.mayatskih@gmail.com>
Cc: linux-kernel@vger.kernel.org, Andi Kleen <andi@firstfloor.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 3/3] Fix copy_user on x86_64
Date: Sat, 28 Jun 2008 11:26:24 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.1.10.0806281108240.4371@hp.linux-foundation.org> (raw)
In-Reply-To: <m37icazgt0.fsf@gravicappa.englab.brq.redhat.com>



On Fri, 27 Jun 2008, Vitaly Mayatskikh wrote:
>
> Added copy_user_64.c instead of copy_user_64.S and
> copy_user_nocache_64.S

Grr, your patches are as attachements, which means that answering to 
themmakes quoting them much harder. Oh well. Anyway, a few more comments:

 - I don't think it's worth it to move what is effectively 100% asm code 
   into a C function is really worth it. It doesn't make things easier to 
   read (often quite the reverse), nor to maintain.

   Using inline asm from C is great if you can actually make the compiler 
   do a noticeable part of the job, like register allocation and a fair 
   amount of setup, but here there is really room for neither.

   The part I wanted to be in C was the copy_user_handle_tail() thing 
   (which you did), nothing more.

   That said - you seem to have done this C conversion correctly, and if 
   you have some inherent reason why you want to use the "asm within C" 
   model, then I don't think this is _fundamentally_ bad. Moving it to 
   within C *can* have advantages (for doing things like adding debugging 
   hooks etc). So if you can explain the thinking a bit more...

 - You've introduced a new pessimization: the original asm code did the 
   jump to the "rep string" vs "the hand-unrolled" loop with

	ALTERNATIVE_JUMP X86_FEATURE_REP_GOOD,copy_user_generic_unrolled,copy_user_generic_string

   which while a nasty and fairly complex macro was actually more clever 
   than the code you replaced it with:

	if (cpu_has(&boot_cpu_data, X86_FEATURE_REP_GOOD))
		return copy_user_generic_string(to, from, len);
	else
		return copy_user_generic_unrolled(to, from, len);

   because the "altinstruction" thing actually does a one-time (boot-time) 
   choice of the code sequence to run, so it _never_ does any conditional 
   jumps at run-time.

   From C code you can use the altinstruction infrastructure to do this, 
   but in fact it would probably be best to keep it in asm (again, the 
   only thing that C function would contain would be the jump one way or 
   the other - there's nothing really helping it being in C, although the 
   same thing can really be done with the C macro

	alternative(non-rep-version, rep-version, X86_FEATURE_REP_GOOD);

   but since you cannot do jumps out of inline asm (because the compiler 
   may have set up a stackframe that needs to be undone etc), you cannot 
   actually do as well in C code as in asm.

Hmm? Sorry for being such a stickler. This code does end up being fairly 
critical, both for correctness and for performance. A lot of user copies 
are actually short (smallish structures, or just small reads and writes), 
and I'd like to make sure that really basic infrastructure like this is 
just basically "known to be optimal", so that we can totally forget about 
it for a few more years.

		Linus

  reply	other threads:[~2008-06-28 18:26 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-27 21:52 [PATCH 3/3] Fix copy_user on x86_64 Vitaly Mayatskikh
2008-06-28 18:26 ` Linus Torvalds [this message]
2008-06-30 15:12   ` Vitaly Mayatskikh
2008-06-30 15:55     ` Linus Torvalds
2008-06-30 16:16       ` Andi Kleen
2008-06-30 18:22       ` Kari Hurtta
2008-07-02 13:48       ` [PATCH 1/2] Introduce copy_user_handle_tail routine Vitaly Mayatskikh
2008-07-02 14:06         ` Andi Kleen
2008-07-02 14:31           ` Vitaly Mayatskikh
2008-07-02 15:06             ` Andi Kleen
2008-07-02 15:32               ` Vitaly Mayatskikh
2008-07-02 15:40                 ` Andi Kleen
2008-07-02 15:58                   ` Vitaly Mayatskikh
2008-07-02 18:54                     ` Andi Kleen
2008-07-03  2:35             ` Linus Torvalds
2008-07-07 12:09               ` Vitaly Mayatskikh
2008-07-07 12:12                 ` Vitaly Mayatskikh
2008-07-07 16:43                   ` Andi Kleen
2008-07-07 16:21                 ` Linus Torvalds
2008-07-07 17:05                   ` Vitaly Mayatskikh
2008-07-09 13:03                   ` Ingo Molnar
2008-07-09 13:16                     ` Vitaly Mayatskikh
2008-07-09 13:52                       ` Ingo Molnar
2008-07-02 13:53       ` [PATCH 2/2] Fix copy_user on x86 Vitaly Mayatskikh
2008-07-02 14:08         ` Andi Kleen
2008-07-02 14:36           ` Vitaly Mayatskikh

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=alpine.LFD.1.10.0806281108240.4371@hp.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=v.mayatskih@gmail.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