Subject: Re: [PATCH 0/9] x86-64 put current in r10
From: Arjan van de Ven <arjan@infradead.org>
To: Matti Aarnio <matti.aarnio@zmailer.org>
Cc: Benjamin LaHaise <bcrl@kvack.org>, Andi Kleen <ak@suse.de>,
       linux-kernel@vger.kernel.org
In-Reply-To: <20051130151847.GE5706@mea-ext.zmailer.org>
References: <20051130042118.GA19112@kvack.org>
	 <20051130151847.GE5706@mea-ext.zmailer.org>
Content-Type: text/plain
Date: Wed, 30 Nov 2005 16:34:33 +0100
Message-Id: <1133364873.2825.41.camel@laptopd505.fenrus.org>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2202
Lines: 51

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/