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
Subject: Re: [PATCH] mask ADT: bitmap and bitop tweaks [1/22]
Date: Tue, 30 Mar 2004 00:00:29 -0800 [thread overview]
Message-ID: <20040330000029.6cd84d7f.pj@sgi.com> (raw)
In-Reply-To: <20040330020637.GA791@holomorphy.com>
> No, the existing standard is to treat the unused bits as "don't cares".
> The difference codewise between the two choices is rather small anyway,
As you have documented in your requested patch to Andrew, the actual
code in 2.6.4 deviated from your intended bitmap model by the details
of cpus_equal(), cpus_empty() and cpus_weight() routines in
cpumask_arith.h.
And 2.6.4 deviates from my bitmap model by a couple of *_complement
implementations and the multi-word CPU_MASK_ALL initializor.
By my model, the CPU_MASK_ALL code for large (multi word mask) systems
is missing the zero'ing of unused bits, in the (rare) case that the
number of valid bits in the mask was not an exact word multiple. And the
*_complement implementations routinely returned masks with the unused
bits set, given input with them not set.
Looking ahead to your next post - I suspect that my model is not the
zeroed tail invariant you describe. My bitmap model makes no promise to
zero out all input tails.
Rather my bitmap model adds the further implementation condition:
If input tails are zero, then output tails will be zero.
By your model, the CPU_MASK_ALL code for small (one word mask) systems
has some redundant code, to zero the unused bits. This CPU_MASK_ALL
could simply be "~0UL", not the more elaborate "(~((cpumask_t)0) >>
(8*sizeof(cpumask_t) - NR_CPUS))".
On further examination, I believe that your model better describes
what has been the design intent for bitmaps.
However my model conforms to yours. Any correct bitmap implementation
of my model is a correct implementation of yours. My model simply
adds the above condition on the implementation.
My change to zero out unused bits in the *_complement operators does not
violate your model. Nor does my change to zero out the unused bits in
the multi-word CPU_MASK_ALL initializor violate your model. You have
repeatedly emphasized that you don't care about the setting of these
bits. Surely you don't care if they are zero, just as you don't care
that the one word CPU_MASK_ALL initialization zeros the unused bits.
==> Note of course that the above model(s) are efforts to describe
the bitmap/bitop code. The model I provide for my new mask ADT is
different - it makes use of the implementation condition above on
bitmaps "Zero tails in yield zero tails out", along with an added
precondition "Don't pass in masks with nonzero tails" to avoid
needing much filtering code.
So - would you consent to my bundling the following changes as a single
patch - that adds to bitmaps the property that "output tails will be
zero if input tails are zero"?
1) Zero unused bits in the *_complement operators.
2) Zero unused bits in CPU_MASK_ALL (multiword).
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.650.933.1373
next prev parent reply other threads:[~2004-03-30 8:57 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-29 12:12 [PATCH] mask ADT: bitmap and bitop tweaks [1/22] Paul Jackson
2004-03-29 23:06 ` Matthew Dobson
2004-03-29 23:52 ` William Lee Irwin III
2004-03-29 23:43 ` Paul Jackson
2004-03-30 1:27 ` Matthew Dobson
2004-03-30 2:06 ` William Lee Irwin III
2004-03-30 1:46 ` Paul Jackson
2004-03-30 2:55 ` William Lee Irwin III
2004-03-30 5:09 ` Paul Jackson
2004-03-30 6:36 ` William Lee Irwin III
2004-03-30 8:00 ` Paul Jackson [this message]
2004-03-30 9:22 ` William Lee Irwin III
2004-03-29 23:50 ` Paul Jackson
2004-03-30 15:53 ` Chris Friesen
2004-03-30 18:30 ` Paul Jackson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040330000029.6cd84d7f.pj@sgi.com \
--to=pj@sgi.com \
--cc=akpm@osdl.org \
--cc=colpatch@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@aracnet.com \
--cc=wli@holomorphy.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox