Date: Mon, 22 Mar 2004 17:12:43 -0800
From: Paul Jackson <pj@sgi.com>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: colpatch@us.ibm.com, linux-kernel@vger.kernel.org, mbligh@aracnet.com,
       akpm@osdl.org, haveblue@us.ibm.com, hch@infradead.org
Subject: Re: [PATCH] Introduce nodemask_t ADT [0/7]
Message-Id: <20040322171243.070774e5.pj@sgi.com>
In-Reply-To: <20040320111340.GA2045@holomorphy.com>
References: <1079651064.8149.158.camel@arrakis>
	<20040318165957.592e49d3.pj@sgi.com>
	<1079659184.8149.355.camel@arrakis>
	<20040318175654.435b1639.pj@sgi.com>
	<1079737351.17841.51.camel@arrakis>
	<20040319165928.45107621.pj@sgi.com>
	<20040320031843.GY2045@holomorphy.com>
	<20040320000235.5e72040a.pj@sgi.com>
	<20040320111340.GA2045@holomorphy.com>
Organization: SGI
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1713
Lines: 32

> > The current nested and ifdef'd complexity of the cpumask macro
> > headers works against such efficient coding - it's non-trivial to see
> > just what macros are available. The youngins reading this may not
> > appreciate the value of reducing brain load; but the oldins might.
> 
> It was painful enough just to preserve semantics across such a far-
> ranging set of changes. Ideally, yes, I would have done this in the
> first place.

I'm not trying to get on your case, Bill, for not creating and applying
more various cpumask functions.  Rather I am looking for ways to make
that API easier for others to use and use well.  If the situations that
passed about temporary cpumasks can be collapsed into single calls that
are more efficient, then that is one way to make progress on this.

Taking masks to be a struct of an array of unsigned longs seems to come
pretty close.  The sparc64 arch would want to pass a pointer to this
apparently, rather than the struct itself - faster for them. Some other
smaller archs would _not_ want to pass a pointer, but rather the (one
word, for them) value - avoids a dereference for them.  In arch specific
code, each arch can choose which way works best for them.  I need to
identify any generic code where these preferences collide.

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373
-
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/