Re: [PATCH 0/9] x86-64 put current in r10

From: Andi Kleen (ak_at_suse.de)
Date: 11/30/05

  • Next message: Grzegorz Nosek: "Re: [PATCH] race condition in procfs"
    Date:	Wed, 30 Nov 2005 16:29:06 +0100
    To: Matti Aarnio <matti.aarnio@zmailer.org>
    
    

    On Wed, Nov 30, 2005 at 05:18:47PM +0200, Matti Aarnio wrote:
    > On Tue, Nov 29, 2005 at 11:21:18PM -0500, Benjamin LaHaise wrote:
    > > Date: Tue, 29 Nov 2005 23:21:18 -0500
    > > From: Benjamin LaHaise <bcrl@kvack.org>
    > > To: Andi Kleen <ak@suse.de>
    > > Cc: linux-kernel@vger.kernel.org
    > > Subject: [PATCH 0/9] x86-64 put current in r10
    > >
    > > Hello Andi,
    > >
    > > The following emails contain the patches to convert x86-64 to store current
    > > in r10 (also at http://www.kvack.org/~bcrl/patches/v2.6.15-rc3/). This
    > > provides a significant amount of code savings (~43KB) over the current
    > > use of the per cpu data area. I also tested using r15, but that generated
    > > code that was larger than that generated with r10. This code seems to be
    > > working well for me now (it stands up to 32 and 64 bit processes and ptrace
    > > users) and would be a good candidate for further exposure.
    >
    > I would rather prefer NOT to introduce this at this time.
    > My primary concern is that during "even numbered series" there
    > should not be radical internal ABI/API changes, like this one.

    Hmm? I am not aware of such a constraint.

    It's not very invasive anyways in that it would require changing
    a lot of code.

    > In 2.7 it can be introduced, by all means.
    >
    > Indeed at the moment my thinking is, that X86-64 is way more UNSTABLE,
    > than it should be. (And Linux kernel overall, but that is another story.)

    The actual x86-64 kernel is actually quite stable, most of the reported
    problems (including yours) come from various hardware or firmware
    issues mostly in new platforms. If you use a trusty old chipset
    (e.g. AMD 8111 or Intel E7505) and proven motherboard you're usually ok.

    -Andi

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Grzegorz Nosek: "Re: [PATCH] race condition in procfs"

    Relevant Pages

    • Re: 2.6.0-test6 -- Huh???
      ... | internal details of the Linux kernel. ... Given that my truck is not ... command, I suspect something on your system might have an unhappy script ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Linux-2.6.12
      ... Just fills me with confidence about the GPL'd nature of this driver. ... * downright wrong changes to the Linux kernel that occurred in ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Non-GPL export of invalidate_mmap_range
      ... but it's hard to see the relevance of this to your patch. ... it was NOT a derived work. ... if a the Linux kernel must be modified in order ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [RFC] Microcode Update Driver for AMD K8 CPUs
      ... >>Also I suspect the driver won't work very well on SMP. ... Andi: Can you explain to me, why you think that the module would not ... Danny van Dyk ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • [PATCH] ppc64: update g5_defconfig
      ... cramfs (later is needed for ppl trying to install fedora, ... -# Linux kernel version: 2.6.9-rc2 ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)