Date: Thu, 3 Jun 2004 22:01:07 -0700
From: "David S. Miller" <davem@redhat.com>
To: Paul Jackson <pj@sgi.com>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, ak@muc.de,
       ashok.raj@intel.com, hch@infradead.org, jbarnes@sgi.com,
       joe.korty@ccur.com, manfred@colorfullife.com, colpatch@us.ibm.com,
       mikpe@csd.uu.se, nickpiggin@yahoo.com.au, rusty@rustcorp.com.au,
       Simon.Derr@bull.net, wli@holomorphy.com
Subject: Re: [PATCH] cpumask 5/10 rewrite cpumask.h - single bitmap based
 implementation
Message-Id: <20040603220107.7590cbcc.davem@redhat.com>
In-Reply-To: <20040603220224.73cd8d44.pj@sgi.com>
References: <20040603094339.03ddfd42.pj@sgi.com>
	<20040603101010.4b15734a.pj@sgi.com>
	<20040603170725.4b3f8b34.akpm@osdl.org>
	<20040603194755.667e584b.pj@sgi.com>
	<20040603195409.11d4aec2.davem@redhat.com>
	<20040603220224.73cd8d44.pj@sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1018
Lines: 24

On Thu, 3 Jun 2004 22:02:24 -0700
Paul Jackson <pj@sgi.com> wrote:

> The generic only is quite a bit simpler - it has some 26 fewer kernel
> source files, and it saves sparc64 some 1144 bytes of kernel text space,
> as measured by Andrew.

I bet if you do a sparc32 build, you'll get larger text size
and more leaf functions will need stack frames.

> I really don't want to go 'back' to the fancy version.  If a particular
> architecture has specific additional needs, I'm certainly open to
> hearing the justifications, tradeoffs and suggestions for ways to meet
> those needs.

Another thing is that only newer gcc's are good at changing structure
accesses such that they are optimized as aggregates when possible.

You're the one doing the work, so it's up to you. :-)
-
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/