public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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