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

From: Arjan van de Ven (arjan_at_infradead.org)
Date: 11/30/05

  • Next message: OGAWA Hirofumi: "Re: FAT:Filesystem panic"
    To: Matti Aarnio <matti.aarnio@zmailer.org>
    Date:	Wed, 30 Nov 2005 16:34:33 +0100
    
    

    On Wed, 2005-11-30 at 17:18 +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.

    this isn't a radical API change actually, and.. well there is no kernel
    ABI. If you care about ABI.. that breaks all the time anyway. Not just a
    little bit, but highly radical.

    > In 2.7 it can be introduced, by all means.

    There is no 2.7, and the current development model also is that there
    won't be one until the development model changes.

    > 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 funny thing is that this is a very localized change compared to many
    of the other things going on, and unlikely to cause any major issues
    with the kernel code. And the changes have clear gains in size and
    probably also in speed (segment accesses are not cheap)

    So personally I don't think your objections make sense in todays
    reality.

    Greetings,
        Arjan van de Ven

    -
    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: OGAWA Hirofumi: "Re: FAT:Filesystem panic"

    Relevant Pages

    • Re: 2.6: unused code under drivers/message/fusion/
      ... > considering for the kernel inclusion at least until 2.7. ... this is a slightly abbreviated version of the development model ... There had been need of rain for many days. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] delete devfs
      ... > Could anyone please explain this mysterious "new development model of ... > the kernel"? ... It would not be nice with LWN. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Reviving the concept of a stable series (was Re: starting with 2.7)
      ... kernel support services. ... If progress is to be made in the development model for Linux, ... > and nurture talented, more mature, or eccentric developers that love ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • [PATCH TRIVIAL] i386/Kconfig: correct minor typo
      ... Compile the kernel with -mregparm=3. ... This uses an different ABI ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [INFO] Kernel strict versioning
      ... The following kernel packages are parts of Fedora Core 3: ... each with a different ABI. ... Being modular has nothing to do with the "problem" (except it's probably ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)