2019-06-03 05:44:46 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* lib/bitmap.c
|
|
|
|
* Helper functions for bitmap.h.
|
|
|
|
*/
|
2021-03-15 09:13:55 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
#include <linux/bitmap.h>
|
|
|
|
#include <linux/bitops.h>
|
2021-03-15 09:13:55 +00:00
|
|
|
#include <linux/ctype.h>
|
2021-03-15 09:13:56 +00:00
|
|
|
#include <linux/device.h>
|
2021-03-15 09:13:55 +00:00
|
|
|
#include <linux/export.h>
|
2018-08-01 22:42:56 +00:00
|
|
|
#include <linux/slab.h>
|
2019-05-14 22:43:14 +00:00
|
|
|
|
2017-10-16 23:32:51 +00:00
|
|
|
/**
|
|
|
|
* DOC: bitmap introduction
|
|
|
|
*
|
2020-10-16 03:10:45 +00:00
|
|
|
* bitmaps provide an array of bits, implemented using an
|
2005-04-16 22:20:36 +00:00
|
|
|
* array of unsigned longs. The number of valid bits in a
|
|
|
|
* given bitmap does _not_ need to be an exact multiple of
|
|
|
|
* BITS_PER_LONG.
|
|
|
|
*
|
|
|
|
* The possible unused bits in the last, partially used word
|
|
|
|
* of a bitmap are 'don't care'. The implementation makes
|
|
|
|
* no particular effort to keep them zero. It ensures that
|
|
|
|
* their value will not affect the results of any operation.
|
|
|
|
* The bitmap operations that return Boolean (bitmap_empty,
|
|
|
|
* for example) or scalar (bitmap_weight, for example) results
|
|
|
|
* carefully filter out these unused bits from impacting their
|
|
|
|
* results.
|
|
|
|
*
|
|
|
|
* The byte ordering of bitmaps is more natural on little
|
|
|
|
* endian architectures. See the big-endian headers
|
|
|
|
* include/asm-ppc64/bitops.h and include/asm-s390/bitops.h
|
|
|
|
* for the best explanations of this ordering.
|
|
|
|
*/
|
|
|
|
|
2022-05-18 20:52:22 +00:00
|
|
|
bool __bitmap_equal(const unsigned long *bitmap1,
|
|
|
|
const unsigned long *bitmap2, unsigned int bits)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2014-08-06 23:09:53 +00:00
|
|
|
unsigned int k, lim = bits/BITS_PER_LONG;
|
2005-04-16 22:20:36 +00:00
|
|
|
for (k = 0; k < lim; ++k)
|
|
|
|
if (bitmap1[k] != bitmap2[k])
|
2022-05-18 20:52:22 +00:00
|
|
|
return false;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
if (bits % BITS_PER_LONG)
|
|
|
|
if ((bitmap1[k] ^ bitmap2[k]) & BITMAP_LAST_WORD_MASK(bits))
|
2022-05-18 20:52:22 +00:00
|
|
|
return false;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2022-05-18 20:52:22 +00:00
|
|
|
return true;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__bitmap_equal);
|
|
|
|
|
2019-07-22 18:47:24 +00:00
|
|
|
bool __bitmap_or_equal(const unsigned long *bitmap1,
|
|
|
|
const unsigned long *bitmap2,
|
|
|
|
const unsigned long *bitmap3,
|
|
|
|
unsigned int bits)
|
|
|
|
{
|
|
|
|
unsigned int k, lim = bits / BITS_PER_LONG;
|
|
|
|
unsigned long tmp;
|
|
|
|
|
|
|
|
for (k = 0; k < lim; ++k) {
|
|
|
|
if ((bitmap1[k] | bitmap2[k]) != bitmap3[k])
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!(bits % BITS_PER_LONG))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
tmp = (bitmap1[k] | bitmap2[k]) ^ bitmap3[k];
|
|
|
|
return (tmp & BITMAP_LAST_WORD_MASK(bits)) == 0;
|
|
|
|
}
|
|
|
|
|
2014-08-06 23:09:55 +00:00
|
|
|
void __bitmap_complement(unsigned long *dst, const unsigned long *src, unsigned int bits)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2018-06-08 00:10:41 +00:00
|
|
|
unsigned int k, lim = BITS_TO_LONGS(bits);
|
2005-04-16 22:20:36 +00:00
|
|
|
for (k = 0; k < lim; ++k)
|
|
|
|
dst[k] = ~src[k];
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__bitmap_complement);
|
|
|
|
|
2007-02-10 09:45:59 +00:00
|
|
|
/**
|
2005-04-16 22:20:36 +00:00
|
|
|
* __bitmap_shift_right - logical right shift of the bits in a bitmap
|
2007-03-01 04:12:13 +00:00
|
|
|
* @dst : destination bitmap
|
|
|
|
* @src : source bitmap
|
|
|
|
* @shift : shift by this many bits
|
2015-02-13 22:36:02 +00:00
|
|
|
* @nbits : bitmap size, in bits
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
|
|
|
* Shifting right (dividing) means moving bits in the MS -> LS bit
|
|
|
|
* direction. Zeros are fed into the vacated MS positions and the
|
|
|
|
* LS bits shifted off the bottom are lost.
|
|
|
|
*/
|
2015-02-13 22:36:02 +00:00
|
|
|
void __bitmap_shift_right(unsigned long *dst, const unsigned long *src,
|
|
|
|
unsigned shift, unsigned nbits)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2015-02-13 22:36:10 +00:00
|
|
|
unsigned k, lim = BITS_TO_LONGS(nbits);
|
2015-02-13 22:36:02 +00:00
|
|
|
unsigned off = shift/BITS_PER_LONG, rem = shift % BITS_PER_LONG;
|
2015-02-13 22:36:10 +00:00
|
|
|
unsigned long mask = BITMAP_LAST_WORD_MASK(nbits);
|
2005-04-16 22:20:36 +00:00
|
|
|
for (k = 0; off + k < lim; ++k) {
|
|
|
|
unsigned long upper, lower;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If shift is not word aligned, take lower rem bits of
|
|
|
|
* word above and make them the top rem bits of result.
|
|
|
|
*/
|
|
|
|
if (!rem || off + k + 1 >= lim)
|
|
|
|
upper = 0;
|
|
|
|
else {
|
|
|
|
upper = src[off + k + 1];
|
2015-02-13 22:36:10 +00:00
|
|
|
if (off + k + 1 == lim - 1)
|
2005-04-16 22:20:36 +00:00
|
|
|
upper &= mask;
|
2015-02-13 22:36:05 +00:00
|
|
|
upper <<= (BITS_PER_LONG - rem);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
lower = src[off + k];
|
2015-02-13 22:36:10 +00:00
|
|
|
if (off + k == lim - 1)
|
2005-04-16 22:20:36 +00:00
|
|
|
lower &= mask;
|
2015-02-13 22:36:05 +00:00
|
|
|
lower >>= rem;
|
|
|
|
dst[k] = lower | upper;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
if (off)
|
|
|
|
memset(&dst[lim - off], 0, off*sizeof(unsigned long));
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__bitmap_shift_right);
|
|
|
|
|
|
|
|
|
2007-02-10 09:45:59 +00:00
|
|
|
/**
|
2005-04-16 22:20:36 +00:00
|
|
|
* __bitmap_shift_left - logical left shift of the bits in a bitmap
|
2007-03-01 04:12:13 +00:00
|
|
|
* @dst : destination bitmap
|
|
|
|
* @src : source bitmap
|
|
|
|
* @shift : shift by this many bits
|
2015-02-13 22:36:13 +00:00
|
|
|
* @nbits : bitmap size, in bits
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
|
|
|
* Shifting left (multiplying) means moving bits in the LS -> MS
|
|
|
|
* direction. Zeros are fed into the vacated LS bit positions
|
|
|
|
* and those MS bits shifted off the top are lost.
|
|
|
|
*/
|
|
|
|
|
2015-02-13 22:36:13 +00:00
|
|
|
void __bitmap_shift_left(unsigned long *dst, const unsigned long *src,
|
|
|
|
unsigned int shift, unsigned int nbits)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2015-02-13 22:36:13 +00:00
|
|
|
int k;
|
2015-02-13 22:36:19 +00:00
|
|
|
unsigned int lim = BITS_TO_LONGS(nbits);
|
2015-02-13 22:36:13 +00:00
|
|
|
unsigned int off = shift/BITS_PER_LONG, rem = shift % BITS_PER_LONG;
|
2005-04-16 22:20:36 +00:00
|
|
|
for (k = lim - off - 1; k >= 0; --k) {
|
|
|
|
unsigned long upper, lower;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If shift is not word aligned, take upper rem bits of
|
|
|
|
* word below and make them the bottom rem bits of result.
|
|
|
|
*/
|
|
|
|
if (rem && k > 0)
|
2015-02-13 22:36:16 +00:00
|
|
|
lower = src[k - 1] >> (BITS_PER_LONG - rem);
|
2005-04-16 22:20:36 +00:00
|
|
|
else
|
|
|
|
lower = 0;
|
2015-02-13 22:36:19 +00:00
|
|
|
upper = src[k] << rem;
|
2015-02-13 22:36:16 +00:00
|
|
|
dst[k + off] = lower | upper;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
if (off)
|
|
|
|
memset(dst, 0, off*sizeof(unsigned long));
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__bitmap_shift_left);
|
|
|
|
|
2020-01-21 23:17:54 +00:00
|
|
|
/**
|
|
|
|
* bitmap_cut() - remove bit region from bitmap and right shift remaining bits
|
|
|
|
* @dst: destination bitmap, might overlap with src
|
|
|
|
* @src: source bitmap
|
|
|
|
* @first: start bit of region to be removed
|
|
|
|
* @cut: number of bits to remove
|
|
|
|
* @nbits: bitmap size, in bits
|
|
|
|
*
|
|
|
|
* Set the n-th bit of @dst iff the n-th bit of @src is set and
|
|
|
|
* n is less than @first, or the m-th bit of @src is set for any
|
|
|
|
* m such that @first <= n < nbits, and m = n + @cut.
|
|
|
|
*
|
|
|
|
* In pictures, example for a big-endian 32-bit architecture:
|
|
|
|
*
|
2020-04-14 16:48:59 +00:00
|
|
|
* The @src bitmap is::
|
2020-01-21 23:17:54 +00:00
|
|
|
*
|
2020-04-14 16:48:59 +00:00
|
|
|
* 31 63
|
|
|
|
* | |
|
|
|
|
* 10000000 11000001 11110010 00010101 10000000 11000001 01110010 00010101
|
|
|
|
* | | | |
|
|
|
|
* 16 14 0 32
|
2020-01-21 23:17:54 +00:00
|
|
|
*
|
2020-04-14 16:48:59 +00:00
|
|
|
* if @cut is 3, and @first is 14, bits 14-16 in @src are cut and @dst is::
|
|
|
|
*
|
|
|
|
* 31 63
|
|
|
|
* | |
|
|
|
|
* 10110000 00011000 00110010 00010101 00010000 00011000 00101110 01000010
|
|
|
|
* | | |
|
|
|
|
* 14 (bit 17 0 32
|
|
|
|
* from @src)
|
2020-01-21 23:17:54 +00:00
|
|
|
*
|
|
|
|
* Note that @dst and @src might overlap partially or entirely.
|
|
|
|
*
|
|
|
|
* This is implemented in the obvious way, with a shift and carry
|
|
|
|
* step for each moved bit. Optimisation is left as an exercise
|
|
|
|
* for the compiler.
|
|
|
|
*/
|
|
|
|
void bitmap_cut(unsigned long *dst, const unsigned long *src,
|
|
|
|
unsigned int first, unsigned int cut, unsigned int nbits)
|
|
|
|
{
|
|
|
|
unsigned int len = BITS_TO_LONGS(nbits);
|
|
|
|
unsigned long keep = 0, carry;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (first % BITS_PER_LONG) {
|
|
|
|
keep = src[first / BITS_PER_LONG] &
|
|
|
|
(~0UL >> (BITS_PER_LONG - first % BITS_PER_LONG));
|
|
|
|
}
|
|
|
|
|
2020-08-12 01:34:29 +00:00
|
|
|
memmove(dst, src, len * sizeof(*dst));
|
|
|
|
|
2020-01-21 23:17:54 +00:00
|
|
|
while (cut--) {
|
|
|
|
for (i = first / BITS_PER_LONG; i < len; i++) {
|
|
|
|
if (i < len - 1)
|
|
|
|
carry = dst[i + 1] & 1UL;
|
|
|
|
else
|
|
|
|
carry = 0;
|
|
|
|
|
|
|
|
dst[i] = (dst[i] >> 1) | (carry << (BITS_PER_LONG - 1));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
dst[first / BITS_PER_LONG] &= ~0UL << (first % BITS_PER_LONG);
|
|
|
|
dst[first / BITS_PER_LONG] |= keep;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(bitmap_cut);
|
|
|
|
|
2022-07-01 12:54:24 +00:00
|
|
|
bool __bitmap_and(unsigned long *dst, const unsigned long *bitmap1,
|
2014-08-06 23:09:59 +00:00
|
|
|
const unsigned long *bitmap2, unsigned int bits)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2014-08-06 23:09:59 +00:00
|
|
|
unsigned int k;
|
2014-08-06 23:10:22 +00:00
|
|
|
unsigned int lim = bits/BITS_PER_LONG;
|
2009-08-21 16:26:15 +00:00
|
|
|
unsigned long result = 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2014-08-06 23:10:22 +00:00
|
|
|
for (k = 0; k < lim; k++)
|
2009-08-21 16:26:15 +00:00
|
|
|
result |= (dst[k] = bitmap1[k] & bitmap2[k]);
|
2014-08-06 23:10:22 +00:00
|
|
|
if (bits % BITS_PER_LONG)
|
|
|
|
result |= (dst[k] = bitmap1[k] & bitmap2[k] &
|
|
|
|
BITMAP_LAST_WORD_MASK(bits));
|
2009-08-21 16:26:15 +00:00
|
|
|
return result != 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__bitmap_and);
|
|
|
|
|
|
|
|
void __bitmap_or(unsigned long *dst, const unsigned long *bitmap1,
|
2014-08-06 23:09:59 +00:00
|
|
|
const unsigned long *bitmap2, unsigned int bits)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2014-08-06 23:09:59 +00:00
|
|
|
unsigned int k;
|
|
|
|
unsigned int nr = BITS_TO_LONGS(bits);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
for (k = 0; k < nr; k++)
|
|
|
|
dst[k] = bitmap1[k] | bitmap2[k];
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__bitmap_or);
|
|
|
|
|
|
|
|
void __bitmap_xor(unsigned long *dst, const unsigned long *bitmap1,
|
2014-08-06 23:09:59 +00:00
|
|
|
const unsigned long *bitmap2, unsigned int bits)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2014-08-06 23:09:59 +00:00
|
|
|
unsigned int k;
|
|
|
|
unsigned int nr = BITS_TO_LONGS(bits);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
for (k = 0; k < nr; k++)
|
|
|
|
dst[k] = bitmap1[k] ^ bitmap2[k];
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__bitmap_xor);
|
|
|
|
|
2022-07-01 12:54:24 +00:00
|
|
|
bool __bitmap_andnot(unsigned long *dst, const unsigned long *bitmap1,
|
2014-08-06 23:09:59 +00:00
|
|
|
const unsigned long *bitmap2, unsigned int bits)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2014-08-06 23:09:59 +00:00
|
|
|
unsigned int k;
|
2014-08-06 23:10:24 +00:00
|
|
|
unsigned int lim = bits/BITS_PER_LONG;
|
2009-08-21 16:26:15 +00:00
|
|
|
unsigned long result = 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2014-08-06 23:10:24 +00:00
|
|
|
for (k = 0; k < lim; k++)
|
2009-08-21 16:26:15 +00:00
|
|
|
result |= (dst[k] = bitmap1[k] & ~bitmap2[k]);
|
2014-08-06 23:10:24 +00:00
|
|
|
if (bits % BITS_PER_LONG)
|
|
|
|
result |= (dst[k] = bitmap1[k] & ~bitmap2[k] &
|
|
|
|
BITMAP_LAST_WORD_MASK(bits));
|
2009-08-21 16:26:15 +00:00
|
|
|
return result != 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__bitmap_andnot);
|
|
|
|
|
2019-12-05 00:53:26 +00:00
|
|
|
void __bitmap_replace(unsigned long *dst,
|
|
|
|
const unsigned long *old, const unsigned long *new,
|
|
|
|
const unsigned long *mask, unsigned int nbits)
|
|
|
|
{
|
|
|
|
unsigned int k;
|
|
|
|
unsigned int nr = BITS_TO_LONGS(nbits);
|
|
|
|
|
|
|
|
for (k = 0; k < nr; k++)
|
|
|
|
dst[k] = (old[k] & ~mask[k]) | (new[k] & mask[k]);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__bitmap_replace);
|
|
|
|
|
2022-05-18 20:52:22 +00:00
|
|
|
bool __bitmap_intersects(const unsigned long *bitmap1,
|
|
|
|
const unsigned long *bitmap2, unsigned int bits)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2014-08-06 23:10:01 +00:00
|
|
|
unsigned int k, lim = bits/BITS_PER_LONG;
|
2005-04-16 22:20:36 +00:00
|
|
|
for (k = 0; k < lim; ++k)
|
|
|
|
if (bitmap1[k] & bitmap2[k])
|
2022-05-18 20:52:22 +00:00
|
|
|
return true;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
if (bits % BITS_PER_LONG)
|
|
|
|
if ((bitmap1[k] & bitmap2[k]) & BITMAP_LAST_WORD_MASK(bits))
|
2022-05-18 20:52:22 +00:00
|
|
|
return true;
|
|
|
|
return false;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__bitmap_intersects);
|
|
|
|
|
2022-05-18 20:52:22 +00:00
|
|
|
bool __bitmap_subset(const unsigned long *bitmap1,
|
|
|
|
const unsigned long *bitmap2, unsigned int bits)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2014-08-06 23:10:03 +00:00
|
|
|
unsigned int k, lim = bits/BITS_PER_LONG;
|
2005-04-16 22:20:36 +00:00
|
|
|
for (k = 0; k < lim; ++k)
|
|
|
|
if (bitmap1[k] & ~bitmap2[k])
|
2022-05-18 20:52:22 +00:00
|
|
|
return false;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
if (bits % BITS_PER_LONG)
|
|
|
|
if ((bitmap1[k] & ~bitmap2[k]) & BITMAP_LAST_WORD_MASK(bits))
|
2022-05-18 20:52:22 +00:00
|
|
|
return false;
|
|
|
|
return true;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__bitmap_subset);
|
|
|
|
|
2022-09-18 03:07:12 +00:00
|
|
|
#define BITMAP_WEIGHT(FETCH, bits) \
|
|
|
|
({ \
|
|
|
|
unsigned int __bits = (bits), idx, w = 0; \
|
|
|
|
\
|
|
|
|
for (idx = 0; idx < __bits / BITS_PER_LONG; idx++) \
|
|
|
|
w += hweight_long(FETCH); \
|
|
|
|
\
|
|
|
|
if (__bits % BITS_PER_LONG) \
|
|
|
|
w += hweight_long((FETCH) & BITMAP_LAST_WORD_MASK(__bits)); \
|
|
|
|
\
|
|
|
|
w; \
|
|
|
|
})
|
|
|
|
|
2022-08-08 00:52:35 +00:00
|
|
|
unsigned int __bitmap_weight(const unsigned long *bitmap, unsigned int bits)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2022-09-18 03:07:12 +00:00
|
|
|
return BITMAP_WEIGHT(bitmap[idx], bits);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__bitmap_weight);
|
|
|
|
|
2022-09-18 03:07:12 +00:00
|
|
|
unsigned int __bitmap_weight_and(const unsigned long *bitmap1,
|
|
|
|
const unsigned long *bitmap2, unsigned int bits)
|
|
|
|
{
|
|
|
|
return BITMAP_WEIGHT(bitmap1[idx] & bitmap2[idx], bits);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__bitmap_weight_and);
|
|
|
|
|
2024-01-29 06:21:04 +00:00
|
|
|
unsigned int __bitmap_weight_andnot(const unsigned long *bitmap1,
|
|
|
|
const unsigned long *bitmap2, unsigned int bits)
|
|
|
|
{
|
|
|
|
return BITMAP_WEIGHT(bitmap1[idx] & ~bitmap2[idx], bits);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__bitmap_weight_andnot);
|
|
|
|
|
2017-07-10 22:51:29 +00:00
|
|
|
void __bitmap_set(unsigned long *map, unsigned int start, int len)
|
2009-12-16 00:48:25 +00:00
|
|
|
{
|
|
|
|
unsigned long *p = map + BIT_WORD(start);
|
2014-08-06 23:10:07 +00:00
|
|
|
const unsigned int size = start + len;
|
2009-12-16 00:48:25 +00:00
|
|
|
int bits_to_set = BITS_PER_LONG - (start % BITS_PER_LONG);
|
|
|
|
unsigned long mask_to_set = BITMAP_FIRST_WORD_MASK(start);
|
|
|
|
|
2014-08-06 23:10:07 +00:00
|
|
|
while (len - bits_to_set >= 0) {
|
2009-12-16 00:48:25 +00:00
|
|
|
*p |= mask_to_set;
|
2014-08-06 23:10:07 +00:00
|
|
|
len -= bits_to_set;
|
2009-12-16 00:48:25 +00:00
|
|
|
bits_to_set = BITS_PER_LONG;
|
|
|
|
mask_to_set = ~0UL;
|
|
|
|
p++;
|
|
|
|
}
|
2014-08-06 23:10:07 +00:00
|
|
|
if (len) {
|
2009-12-16 00:48:25 +00:00
|
|
|
mask_to_set &= BITMAP_LAST_WORD_MASK(size);
|
|
|
|
*p |= mask_to_set;
|
|
|
|
}
|
|
|
|
}
|
2017-07-10 22:51:29 +00:00
|
|
|
EXPORT_SYMBOL(__bitmap_set);
|
2009-12-16 00:48:25 +00:00
|
|
|
|
2017-07-10 22:51:29 +00:00
|
|
|
void __bitmap_clear(unsigned long *map, unsigned int start, int len)
|
2009-12-16 00:48:25 +00:00
|
|
|
{
|
|
|
|
unsigned long *p = map + BIT_WORD(start);
|
2014-08-06 23:10:10 +00:00
|
|
|
const unsigned int size = start + len;
|
2009-12-16 00:48:25 +00:00
|
|
|
int bits_to_clear = BITS_PER_LONG - (start % BITS_PER_LONG);
|
|
|
|
unsigned long mask_to_clear = BITMAP_FIRST_WORD_MASK(start);
|
|
|
|
|
2014-08-06 23:10:10 +00:00
|
|
|
while (len - bits_to_clear >= 0) {
|
2009-12-16 00:48:25 +00:00
|
|
|
*p &= ~mask_to_clear;
|
2014-08-06 23:10:10 +00:00
|
|
|
len -= bits_to_clear;
|
2009-12-16 00:48:25 +00:00
|
|
|
bits_to_clear = BITS_PER_LONG;
|
|
|
|
mask_to_clear = ~0UL;
|
|
|
|
p++;
|
|
|
|
}
|
2014-08-06 23:10:10 +00:00
|
|
|
if (len) {
|
2009-12-16 00:48:25 +00:00
|
|
|
mask_to_clear &= BITMAP_LAST_WORD_MASK(size);
|
|
|
|
*p &= ~mask_to_clear;
|
|
|
|
}
|
|
|
|
}
|
2017-07-10 22:51:29 +00:00
|
|
|
EXPORT_SYMBOL(__bitmap_clear);
|
2009-12-16 00:48:25 +00:00
|
|
|
|
2014-12-13 00:54:45 +00:00
|
|
|
/**
|
|
|
|
* bitmap_find_next_zero_area_off - find a contiguous aligned zero area
|
2009-12-16 00:48:25 +00:00
|
|
|
* @map: The address to base the search on
|
|
|
|
* @size: The bitmap size in bits
|
|
|
|
* @start: The bitnumber to start searching at
|
|
|
|
* @nr: The number of zeroed bits we're looking for
|
|
|
|
* @align_mask: Alignment mask for zero area
|
2014-12-13 00:54:45 +00:00
|
|
|
* @align_offset: Alignment offset for zero area.
|
2009-12-16 00:48:25 +00:00
|
|
|
*
|
|
|
|
* The @align_mask should be one less than a power of 2; the effect is that
|
2014-12-13 00:54:45 +00:00
|
|
|
* the bit offset of all zero areas this function finds plus @align_offset
|
|
|
|
* is multiple of that power of 2.
|
2009-12-16 00:48:25 +00:00
|
|
|
*/
|
2014-12-13 00:54:45 +00:00
|
|
|
unsigned long bitmap_find_next_zero_area_off(unsigned long *map,
|
|
|
|
unsigned long size,
|
|
|
|
unsigned long start,
|
|
|
|
unsigned int nr,
|
|
|
|
unsigned long align_mask,
|
|
|
|
unsigned long align_offset)
|
2009-12-16 00:48:25 +00:00
|
|
|
{
|
|
|
|
unsigned long index, end, i;
|
|
|
|
again:
|
|
|
|
index = find_next_zero_bit(map, size, start);
|
|
|
|
|
|
|
|
/* Align allocation */
|
2014-12-13 00:54:45 +00:00
|
|
|
index = __ALIGN_MASK(index + align_offset, align_mask) - align_offset;
|
2009-12-16 00:48:25 +00:00
|
|
|
|
|
|
|
end = index + nr;
|
|
|
|
if (end > size)
|
|
|
|
return end;
|
|
|
|
i = find_next_bit(map, end, index);
|
|
|
|
if (i < end) {
|
|
|
|
start = i + 1;
|
|
|
|
goto again;
|
|
|
|
}
|
|
|
|
return index;
|
|
|
|
}
|
2014-12-13 00:54:45 +00:00
|
|
|
EXPORT_SYMBOL(bitmap_find_next_zero_area_off);
|
2009-12-16 00:48:25 +00:00
|
|
|
|
2007-02-10 09:45:59 +00:00
|
|
|
/**
|
2010-03-05 21:43:17 +00:00
|
|
|
* bitmap_pos_to_ord - find ordinal of set bit at given position in bitmap
|
2005-10-30 23:02:33 +00:00
|
|
|
* @buf: pointer to a bitmap
|
2015-02-12 23:02:07 +00:00
|
|
|
* @pos: a bit position in @buf (0 <= @pos < @nbits)
|
|
|
|
* @nbits: number of valid bit positions in @buf
|
2005-10-30 23:02:33 +00:00
|
|
|
*
|
2015-02-12 23:02:07 +00:00
|
|
|
* Map the bit at position @pos in @buf (of length @nbits) to the
|
2005-10-30 23:02:33 +00:00
|
|
|
* ordinal of which set bit it is. If it is not set or if @pos
|
[PATCH] cpuset: better bitmap remap defaults
Fix the default behaviour for the remap operators in bitmap, cpumask and
nodemask.
As previously submitted, the pair of masks <A, B> defined a map of the
positions of the set bits in A to the corresponding bits in B. This is still
true.
The issue is how to map the other positions, corresponding to the unset (0)
bits in A. As previously submitted, they were all mapped to the first set bit
position in B, a constant map.
When I tried to code per-vma mempolicy rebinding using these remap operators,
I realized this was wrong.
This patch changes the default to map all the unset bit positions in A to the
same positions in B, the identity map.
For example, if A has bits 4-7 set, and B has bits 9-12 set, then the map
defined by the pair <A, B> maps each bit position in the first 32 bits as
follows:
0 ==> 0
...
3 ==> 3
4 ==> 9
...
7 ==> 12
8 ==> 8
9 ==> 9
...
31 ==> 31
This now corresponds to the typical behaviour desired when migrating pages and
policies from one cpuset to another.
The pages on nodes within the original cpuset, and the references in memory
policies to nodes within the original cpuset, are migrated to the
corresponding cpuset-relative nodes in the destination cpuset. Other pages
and node references are left untouched.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-08 09:01:46 +00:00
|
|
|
* is not a valid bit position, map to -1.
|
2005-10-30 23:02:33 +00:00
|
|
|
*
|
|
|
|
* If for example, just bits 4 through 7 are set in @buf, then @pos
|
|
|
|
* values 4 through 7 will get mapped to 0 through 3, respectively,
|
2014-08-06 23:10:14 +00:00
|
|
|
* and other @pos values will get mapped to -1. When @pos value 7
|
2005-10-30 23:02:33 +00:00
|
|
|
* gets mapped to (returns) @ord value 3 in this example, that means
|
|
|
|
* that bit 7 is the 3rd (starting with 0th) set bit in @buf.
|
|
|
|
*
|
|
|
|
* The bit positions 0 through @bits are valid positions in @buf.
|
|
|
|
*/
|
2015-02-12 23:02:07 +00:00
|
|
|
static int bitmap_pos_to_ord(const unsigned long *buf, unsigned int pos, unsigned int nbits)
|
2005-10-30 23:02:33 +00:00
|
|
|
{
|
2015-02-12 23:02:07 +00:00
|
|
|
if (pos >= nbits || !test_bit(pos, buf))
|
[PATCH] cpuset: better bitmap remap defaults
Fix the default behaviour for the remap operators in bitmap, cpumask and
nodemask.
As previously submitted, the pair of masks <A, B> defined a map of the
positions of the set bits in A to the corresponding bits in B. This is still
true.
The issue is how to map the other positions, corresponding to the unset (0)
bits in A. As previously submitted, they were all mapped to the first set bit
position in B, a constant map.
When I tried to code per-vma mempolicy rebinding using these remap operators,
I realized this was wrong.
This patch changes the default to map all the unset bit positions in A to the
same positions in B, the identity map.
For example, if A has bits 4-7 set, and B has bits 9-12 set, then the map
defined by the pair <A, B> maps each bit position in the first 32 bits as
follows:
0 ==> 0
...
3 ==> 3
4 ==> 9
...
7 ==> 12
8 ==> 8
9 ==> 9
...
31 ==> 31
This now corresponds to the typical behaviour desired when migrating pages and
policies from one cpuset to another.
The pages on nodes within the original cpuset, and the references in memory
policies to nodes within the original cpuset, are migrated to the
corresponding cpuset-relative nodes in the destination cpuset. Other pages
and node references are left untouched.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-08 09:01:46 +00:00
|
|
|
return -1;
|
2005-10-30 23:02:33 +00:00
|
|
|
|
2022-09-18 03:07:11 +00:00
|
|
|
return bitmap_weight(buf, pos);
|
2005-10-30 23:02:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* bitmap_remap - Apply map defined by a pair of bitmaps to another bitmap
|
|
|
|
* @dst: remapped result
|
[PATCH] cpuset: better bitmap remap defaults
Fix the default behaviour for the remap operators in bitmap, cpumask and
nodemask.
As previously submitted, the pair of masks <A, B> defined a map of the
positions of the set bits in A to the corresponding bits in B. This is still
true.
The issue is how to map the other positions, corresponding to the unset (0)
bits in A. As previously submitted, they were all mapped to the first set bit
position in B, a constant map.
When I tried to code per-vma mempolicy rebinding using these remap operators,
I realized this was wrong.
This patch changes the default to map all the unset bit positions in A to the
same positions in B, the identity map.
For example, if A has bits 4-7 set, and B has bits 9-12 set, then the map
defined by the pair <A, B> maps each bit position in the first 32 bits as
follows:
0 ==> 0
...
3 ==> 3
4 ==> 9
...
7 ==> 12
8 ==> 8
9 ==> 9
...
31 ==> 31
This now corresponds to the typical behaviour desired when migrating pages and
policies from one cpuset to another.
The pages on nodes within the original cpuset, and the references in memory
policies to nodes within the original cpuset, are migrated to the
corresponding cpuset-relative nodes in the destination cpuset. Other pages
and node references are left untouched.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-08 09:01:46 +00:00
|
|
|
* @src: subset to be remapped
|
2005-10-30 23:02:33 +00:00
|
|
|
* @old: defines domain of map
|
|
|
|
* @new: defines range of map
|
2015-02-12 23:02:13 +00:00
|
|
|
* @nbits: number of bits in each of these bitmaps
|
2005-10-30 23:02:33 +00:00
|
|
|
*
|
|
|
|
* Let @old and @new define a mapping of bit positions, such that
|
|
|
|
* whatever position is held by the n-th set bit in @old is mapped
|
|
|
|
* to the n-th set bit in @new. In the more general case, allowing
|
|
|
|
* for the possibility that the weight 'w' of @new is less than the
|
|
|
|
* weight of @old, map the position of the n-th set bit in @old to
|
|
|
|
* the position of the m-th set bit in @new, where m == n % w.
|
|
|
|
*
|
[PATCH] cpuset: better bitmap remap defaults
Fix the default behaviour for the remap operators in bitmap, cpumask and
nodemask.
As previously submitted, the pair of masks <A, B> defined a map of the
positions of the set bits in A to the corresponding bits in B. This is still
true.
The issue is how to map the other positions, corresponding to the unset (0)
bits in A. As previously submitted, they were all mapped to the first set bit
position in B, a constant map.
When I tried to code per-vma mempolicy rebinding using these remap operators,
I realized this was wrong.
This patch changes the default to map all the unset bit positions in A to the
same positions in B, the identity map.
For example, if A has bits 4-7 set, and B has bits 9-12 set, then the map
defined by the pair <A, B> maps each bit position in the first 32 bits as
follows:
0 ==> 0
...
3 ==> 3
4 ==> 9
...
7 ==> 12
8 ==> 8
9 ==> 9
...
31 ==> 31
This now corresponds to the typical behaviour desired when migrating pages and
policies from one cpuset to another.
The pages on nodes within the original cpuset, and the references in memory
policies to nodes within the original cpuset, are migrated to the
corresponding cpuset-relative nodes in the destination cpuset. Other pages
and node references are left untouched.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-08 09:01:46 +00:00
|
|
|
* If either of the @old and @new bitmaps are empty, or if @src and
|
|
|
|
* @dst point to the same location, then this routine copies @src
|
|
|
|
* to @dst.
|
2005-10-30 23:02:33 +00:00
|
|
|
*
|
[PATCH] cpuset: better bitmap remap defaults
Fix the default behaviour for the remap operators in bitmap, cpumask and
nodemask.
As previously submitted, the pair of masks <A, B> defined a map of the
positions of the set bits in A to the corresponding bits in B. This is still
true.
The issue is how to map the other positions, corresponding to the unset (0)
bits in A. As previously submitted, they were all mapped to the first set bit
position in B, a constant map.
When I tried to code per-vma mempolicy rebinding using these remap operators,
I realized this was wrong.
This patch changes the default to map all the unset bit positions in A to the
same positions in B, the identity map.
For example, if A has bits 4-7 set, and B has bits 9-12 set, then the map
defined by the pair <A, B> maps each bit position in the first 32 bits as
follows:
0 ==> 0
...
3 ==> 3
4 ==> 9
...
7 ==> 12
8 ==> 8
9 ==> 9
...
31 ==> 31
This now corresponds to the typical behaviour desired when migrating pages and
policies from one cpuset to another.
The pages on nodes within the original cpuset, and the references in memory
policies to nodes within the original cpuset, are migrated to the
corresponding cpuset-relative nodes in the destination cpuset. Other pages
and node references are left untouched.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-08 09:01:46 +00:00
|
|
|
* The positions of unset bits in @old are mapped to themselves
|
2023-08-14 17:37:08 +00:00
|
|
|
* (the identity map).
|
2005-10-30 23:02:33 +00:00
|
|
|
*
|
|
|
|
* Apply the above specified mapping to @src, placing the result in
|
|
|
|
* @dst, clearing any bits previously set in @dst.
|
|
|
|
*
|
|
|
|
* For example, lets say that @old has bits 4 through 7 set, and
|
|
|
|
* @new has bits 12 through 15 set. This defines the mapping of bit
|
|
|
|
* position 4 to 12, 5 to 13, 6 to 14 and 7 to 15, and of all other
|
[PATCH] cpuset: better bitmap remap defaults
Fix the default behaviour for the remap operators in bitmap, cpumask and
nodemask.
As previously submitted, the pair of masks <A, B> defined a map of the
positions of the set bits in A to the corresponding bits in B. This is still
true.
The issue is how to map the other positions, corresponding to the unset (0)
bits in A. As previously submitted, they were all mapped to the first set bit
position in B, a constant map.
When I tried to code per-vma mempolicy rebinding using these remap operators,
I realized this was wrong.
This patch changes the default to map all the unset bit positions in A to the
same positions in B, the identity map.
For example, if A has bits 4-7 set, and B has bits 9-12 set, then the map
defined by the pair <A, B> maps each bit position in the first 32 bits as
follows:
0 ==> 0
...
3 ==> 3
4 ==> 9
...
7 ==> 12
8 ==> 8
9 ==> 9
...
31 ==> 31
This now corresponds to the typical behaviour desired when migrating pages and
policies from one cpuset to another.
The pages on nodes within the original cpuset, and the references in memory
policies to nodes within the original cpuset, are migrated to the
corresponding cpuset-relative nodes in the destination cpuset. Other pages
and node references are left untouched.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-08 09:01:46 +00:00
|
|
|
* bit positions unchanged. So if say @src comes into this routine
|
|
|
|
* with bits 1, 5 and 7 set, then @dst should leave with bits 1,
|
|
|
|
* 13 and 15 set.
|
2005-10-30 23:02:33 +00:00
|
|
|
*/
|
|
|
|
void bitmap_remap(unsigned long *dst, const unsigned long *src,
|
|
|
|
const unsigned long *old, const unsigned long *new,
|
2015-02-12 23:02:13 +00:00
|
|
|
unsigned int nbits)
|
2005-10-30 23:02:33 +00:00
|
|
|
{
|
2015-02-12 23:02:13 +00:00
|
|
|
unsigned int oldbit, w;
|
2005-10-30 23:02:33 +00:00
|
|
|
|
|
|
|
if (dst == src) /* following doesn't handle inplace remaps */
|
|
|
|
return;
|
2015-02-12 23:02:13 +00:00
|
|
|
bitmap_zero(dst, nbits);
|
[PATCH] cpuset: better bitmap remap defaults
Fix the default behaviour for the remap operators in bitmap, cpumask and
nodemask.
As previously submitted, the pair of masks <A, B> defined a map of the
positions of the set bits in A to the corresponding bits in B. This is still
true.
The issue is how to map the other positions, corresponding to the unset (0)
bits in A. As previously submitted, they were all mapped to the first set bit
position in B, a constant map.
When I tried to code per-vma mempolicy rebinding using these remap operators,
I realized this was wrong.
This patch changes the default to map all the unset bit positions in A to the
same positions in B, the identity map.
For example, if A has bits 4-7 set, and B has bits 9-12 set, then the map
defined by the pair <A, B> maps each bit position in the first 32 bits as
follows:
0 ==> 0
...
3 ==> 3
4 ==> 9
...
7 ==> 12
8 ==> 8
9 ==> 9
...
31 ==> 31
This now corresponds to the typical behaviour desired when migrating pages and
policies from one cpuset to another.
The pages on nodes within the original cpuset, and the references in memory
policies to nodes within the original cpuset, are migrated to the
corresponding cpuset-relative nodes in the destination cpuset. Other pages
and node references are left untouched.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-08 09:01:46 +00:00
|
|
|
|
2015-02-12 23:02:13 +00:00
|
|
|
w = bitmap_weight(new, nbits);
|
|
|
|
for_each_set_bit(oldbit, src, nbits) {
|
|
|
|
int n = bitmap_pos_to_ord(old, oldbit, nbits);
|
2010-03-05 21:43:18 +00:00
|
|
|
|
[PATCH] cpuset: better bitmap remap defaults
Fix the default behaviour for the remap operators in bitmap, cpumask and
nodemask.
As previously submitted, the pair of masks <A, B> defined a map of the
positions of the set bits in A to the corresponding bits in B. This is still
true.
The issue is how to map the other positions, corresponding to the unset (0)
bits in A. As previously submitted, they were all mapped to the first set bit
position in B, a constant map.
When I tried to code per-vma mempolicy rebinding using these remap operators,
I realized this was wrong.
This patch changes the default to map all the unset bit positions in A to the
same positions in B, the identity map.
For example, if A has bits 4-7 set, and B has bits 9-12 set, then the map
defined by the pair <A, B> maps each bit position in the first 32 bits as
follows:
0 ==> 0
...
3 ==> 3
4 ==> 9
...
7 ==> 12
8 ==> 8
9 ==> 9
...
31 ==> 31
This now corresponds to the typical behaviour desired when migrating pages and
policies from one cpuset to another.
The pages on nodes within the original cpuset, and the references in memory
policies to nodes within the original cpuset, are migrated to the
corresponding cpuset-relative nodes in the destination cpuset. Other pages
and node references are left untouched.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-08 09:01:46 +00:00
|
|
|
if (n < 0 || w == 0)
|
|
|
|
set_bit(oldbit, dst); /* identity map */
|
|
|
|
else
|
2022-09-18 03:07:15 +00:00
|
|
|
set_bit(find_nth_bit(new, nbits, n % w), dst);
|
2005-10-30 23:02:33 +00:00
|
|
|
}
|
|
|
|
}
|
2021-05-10 19:46:29 +00:00
|
|
|
EXPORT_SYMBOL(bitmap_remap);
|
2005-10-30 23:02:33 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* bitmap_bitremap - Apply map defined by a pair of bitmaps to a single bit
|
2006-06-25 12:48:57 +00:00
|
|
|
* @oldbit: bit position to be mapped
|
|
|
|
* @old: defines domain of map
|
|
|
|
* @new: defines range of map
|
|
|
|
* @bits: number of bits in each of these bitmaps
|
2005-10-30 23:02:33 +00:00
|
|
|
*
|
|
|
|
* Let @old and @new define a mapping of bit positions, such that
|
|
|
|
* whatever position is held by the n-th set bit in @old is mapped
|
|
|
|
* to the n-th set bit in @new. In the more general case, allowing
|
|
|
|
* for the possibility that the weight 'w' of @new is less than the
|
|
|
|
* weight of @old, map the position of the n-th set bit in @old to
|
|
|
|
* the position of the m-th set bit in @new, where m == n % w.
|
|
|
|
*
|
[PATCH] cpuset: better bitmap remap defaults
Fix the default behaviour for the remap operators in bitmap, cpumask and
nodemask.
As previously submitted, the pair of masks <A, B> defined a map of the
positions of the set bits in A to the corresponding bits in B. This is still
true.
The issue is how to map the other positions, corresponding to the unset (0)
bits in A. As previously submitted, they were all mapped to the first set bit
position in B, a constant map.
When I tried to code per-vma mempolicy rebinding using these remap operators,
I realized this was wrong.
This patch changes the default to map all the unset bit positions in A to the
same positions in B, the identity map.
For example, if A has bits 4-7 set, and B has bits 9-12 set, then the map
defined by the pair <A, B> maps each bit position in the first 32 bits as
follows:
0 ==> 0
...
3 ==> 3
4 ==> 9
...
7 ==> 12
8 ==> 8
9 ==> 9
...
31 ==> 31
This now corresponds to the typical behaviour desired when migrating pages and
policies from one cpuset to another.
The pages on nodes within the original cpuset, and the references in memory
policies to nodes within the original cpuset, are migrated to the
corresponding cpuset-relative nodes in the destination cpuset. Other pages
and node references are left untouched.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-08 09:01:46 +00:00
|
|
|
* The positions of unset bits in @old are mapped to themselves
|
2023-08-14 17:37:08 +00:00
|
|
|
* (the identity map).
|
2005-10-30 23:02:33 +00:00
|
|
|
*
|
|
|
|
* Apply the above specified mapping to bit position @oldbit, returning
|
|
|
|
* the new bit position.
|
|
|
|
*
|
|
|
|
* For example, lets say that @old has bits 4 through 7 set, and
|
|
|
|
* @new has bits 12 through 15 set. This defines the mapping of bit
|
|
|
|
* position 4 to 12, 5 to 13, 6 to 14 and 7 to 15, and of all other
|
[PATCH] cpuset: better bitmap remap defaults
Fix the default behaviour for the remap operators in bitmap, cpumask and
nodemask.
As previously submitted, the pair of masks <A, B> defined a map of the
positions of the set bits in A to the corresponding bits in B. This is still
true.
The issue is how to map the other positions, corresponding to the unset (0)
bits in A. As previously submitted, they were all mapped to the first set bit
position in B, a constant map.
When I tried to code per-vma mempolicy rebinding using these remap operators,
I realized this was wrong.
This patch changes the default to map all the unset bit positions in A to the
same positions in B, the identity map.
For example, if A has bits 4-7 set, and B has bits 9-12 set, then the map
defined by the pair <A, B> maps each bit position in the first 32 bits as
follows:
0 ==> 0
...
3 ==> 3
4 ==> 9
...
7 ==> 12
8 ==> 8
9 ==> 9
...
31 ==> 31
This now corresponds to the typical behaviour desired when migrating pages and
policies from one cpuset to another.
The pages on nodes within the original cpuset, and the references in memory
policies to nodes within the original cpuset, are migrated to the
corresponding cpuset-relative nodes in the destination cpuset. Other pages
and node references are left untouched.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-08 09:01:46 +00:00
|
|
|
* bit positions unchanged. So if say @oldbit is 5, then this routine
|
|
|
|
* returns 13.
|
2005-10-30 23:02:33 +00:00
|
|
|
*/
|
|
|
|
int bitmap_bitremap(int oldbit, const unsigned long *old,
|
|
|
|
const unsigned long *new, int bits)
|
|
|
|
{
|
[PATCH] cpuset: better bitmap remap defaults
Fix the default behaviour for the remap operators in bitmap, cpumask and
nodemask.
As previously submitted, the pair of masks <A, B> defined a map of the
positions of the set bits in A to the corresponding bits in B. This is still
true.
The issue is how to map the other positions, corresponding to the unset (0)
bits in A. As previously submitted, they were all mapped to the first set bit
position in B, a constant map.
When I tried to code per-vma mempolicy rebinding using these remap operators,
I realized this was wrong.
This patch changes the default to map all the unset bit positions in A to the
same positions in B, the identity map.
For example, if A has bits 4-7 set, and B has bits 9-12 set, then the map
defined by the pair <A, B> maps each bit position in the first 32 bits as
follows:
0 ==> 0
...
3 ==> 3
4 ==> 9
...
7 ==> 12
8 ==> 8
9 ==> 9
...
31 ==> 31
This now corresponds to the typical behaviour desired when migrating pages and
policies from one cpuset to another.
The pages on nodes within the original cpuset, and the references in memory
policies to nodes within the original cpuset, are migrated to the
corresponding cpuset-relative nodes in the destination cpuset. Other pages
and node references are left untouched.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-08 09:01:46 +00:00
|
|
|
int w = bitmap_weight(new, bits);
|
|
|
|
int n = bitmap_pos_to_ord(old, oldbit, bits);
|
|
|
|
if (n < 0 || w == 0)
|
|
|
|
return oldbit;
|
|
|
|
else
|
2022-09-18 03:07:15 +00:00
|
|
|
return find_nth_bit(new, bits, n % w);
|
2005-10-30 23:02:33 +00:00
|
|
|
}
|
2021-05-10 19:46:29 +00:00
|
|
|
EXPORT_SYMBOL(bitmap_bitremap);
|
2005-10-30 23:02:33 +00:00
|
|
|
|
2021-05-10 19:46:29 +00:00
|
|
|
#ifdef CONFIG_NUMA
|
mempolicy: add bitmap_onto() and bitmap_fold() operations
The following adds two more bitmap operators, bitmap_onto() and bitmap_fold(),
with the usual cpumask and nodemask wrappers.
The bitmap_onto() operator computes one bitmap relative to another. If the
n-th bit in the origin mask is set, then the m-th bit of the destination mask
will be set, where m is the position of the n-th set bit in the relative mask.
The bitmap_fold() operator folds a bitmap into a second that has bit m set iff
the input bitmap has some bit n set, where m == n mod sz, for the specified sz
value.
There are two substantive changes between this patch and its
predecessor bitmap_relative:
1) Renamed bitmap_relative() to be bitmap_onto().
2) Added bitmap_fold().
The essential motivation for bitmap_onto() is to provide a mechanism for
converting a cpuset-relative CPU or Node mask to an absolute mask. Cpuset
relative masks are written as if the current task were in a cpuset whose CPUs
or Nodes were just the consecutive ones numbered 0..N-1, for some N. The
bitmap_onto() operator is provided in anticipation of adding support for the
first such cpuset relative mask, by the mbind() and set_mempolicy() system
calls, using a planned flag of MPOL_F_RELATIVE_NODES. These bitmap operators
(and their nodemask wrappers, in particular) will be used in code that
converts the user specified cpuset relative memory policy to a specific system
node numbered policy, given the current mems_allowed of the tasks cpuset.
Such cpuset relative mempolicies will address two deficiencies
of the existing interface between cpusets and mempolicies:
1) A task cannot at present reliably establish a cpuset
relative mempolicy because there is an essential race
condition, in that the tasks cpuset may be changed in
between the time the task can query its cpuset placement,
and the time the task can issue the applicable mbind or
set_memplicy system call.
2) A task cannot at present establish what cpuset relative
mempolicy it would like to have, if it is in a smaller
cpuset than it might have mempolicy preferences for,
because the existing interface only allows specifying
mempolicies for nodes currently allowed by the cpuset.
Cpuset relative mempolicies are useful for tasks that don't distinguish
particularly between one CPU or Node and another, but only between how many of
each are allowed, and the proper placement of threads and memory pages on the
various CPUs and Nodes available.
The motivation for the added bitmap_fold() can be seen in the following
example.
Let's say an application has specified some mempolicies that presume 16 memory
nodes, including say a mempolicy that specified MPOL_F_RELATIVE_NODES (cpuset
relative) nodes 12-15. Then lets say that application is crammed into a
cpuset that only has 8 memory nodes, 0-7. If one just uses bitmap_onto(),
this mempolicy, mapped to that cpuset, would ignore the requested relative
nodes above 7, leaving it empty of nodes. That's not good; better to fold the
higher nodes down, so that some nodes are included in the resulting mapped
mempolicy. In this case, the mempolicy nodes 12-15 are taken modulo 8 (the
weight of the mems_allowed of the confining cpuset), resulting in a mempolicy
specifying nodes 4-7.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: <kosaki.motohiro@jp.fujitsu.com>
Cc: <ray-lk@madrabbit.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-28 09:12:29 +00:00
|
|
|
/**
|
|
|
|
* bitmap_onto - translate one bitmap relative to another
|
|
|
|
* @dst: resulting translated bitmap
|
|
|
|
* @orig: original untranslated bitmap
|
|
|
|
* @relmap: bitmap relative to which translated
|
|
|
|
* @bits: number of bits in each of these bitmaps
|
|
|
|
*
|
|
|
|
* Set the n-th bit of @dst iff there exists some m such that the
|
|
|
|
* n-th bit of @relmap is set, the m-th bit of @orig is set, and
|
|
|
|
* the n-th bit of @relmap is also the m-th _set_ bit of @relmap.
|
|
|
|
* (If you understood the previous sentence the first time your
|
|
|
|
* read it, you're overqualified for your current job.)
|
|
|
|
*
|
|
|
|
* In other words, @orig is mapped onto (surjectively) @dst,
|
2014-09-08 16:27:23 +00:00
|
|
|
* using the map { <n, m> | the n-th bit of @relmap is the
|
mempolicy: add bitmap_onto() and bitmap_fold() operations
The following adds two more bitmap operators, bitmap_onto() and bitmap_fold(),
with the usual cpumask and nodemask wrappers.
The bitmap_onto() operator computes one bitmap relative to another. If the
n-th bit in the origin mask is set, then the m-th bit of the destination mask
will be set, where m is the position of the n-th set bit in the relative mask.
The bitmap_fold() operator folds a bitmap into a second that has bit m set iff
the input bitmap has some bit n set, where m == n mod sz, for the specified sz
value.
There are two substantive changes between this patch and its
predecessor bitmap_relative:
1) Renamed bitmap_relative() to be bitmap_onto().
2) Added bitmap_fold().
The essential motivation for bitmap_onto() is to provide a mechanism for
converting a cpuset-relative CPU or Node mask to an absolute mask. Cpuset
relative masks are written as if the current task were in a cpuset whose CPUs
or Nodes were just the consecutive ones numbered 0..N-1, for some N. The
bitmap_onto() operator is provided in anticipation of adding support for the
first such cpuset relative mask, by the mbind() and set_mempolicy() system
calls, using a planned flag of MPOL_F_RELATIVE_NODES. These bitmap operators
(and their nodemask wrappers, in particular) will be used in code that
converts the user specified cpuset relative memory policy to a specific system
node numbered policy, given the current mems_allowed of the tasks cpuset.
Such cpuset relative mempolicies will address two deficiencies
of the existing interface between cpusets and mempolicies:
1) A task cannot at present reliably establish a cpuset
relative mempolicy because there is an essential race
condition, in that the tasks cpuset may be changed in
between the time the task can query its cpuset placement,
and the time the task can issue the applicable mbind or
set_memplicy system call.
2) A task cannot at present establish what cpuset relative
mempolicy it would like to have, if it is in a smaller
cpuset than it might have mempolicy preferences for,
because the existing interface only allows specifying
mempolicies for nodes currently allowed by the cpuset.
Cpuset relative mempolicies are useful for tasks that don't distinguish
particularly between one CPU or Node and another, but only between how many of
each are allowed, and the proper placement of threads and memory pages on the
various CPUs and Nodes available.
The motivation for the added bitmap_fold() can be seen in the following
example.
Let's say an application has specified some mempolicies that presume 16 memory
nodes, including say a mempolicy that specified MPOL_F_RELATIVE_NODES (cpuset
relative) nodes 12-15. Then lets say that application is crammed into a
cpuset that only has 8 memory nodes, 0-7. If one just uses bitmap_onto(),
this mempolicy, mapped to that cpuset, would ignore the requested relative
nodes above 7, leaving it empty of nodes. That's not good; better to fold the
higher nodes down, so that some nodes are included in the resulting mapped
mempolicy. In this case, the mempolicy nodes 12-15 are taken modulo 8 (the
weight of the mems_allowed of the confining cpuset), resulting in a mempolicy
specifying nodes 4-7.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: <kosaki.motohiro@jp.fujitsu.com>
Cc: <ray-lk@madrabbit.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-28 09:12:29 +00:00
|
|
|
* m-th set bit of @relmap }.
|
|
|
|
*
|
|
|
|
* Any set bits in @orig above bit number W, where W is the
|
|
|
|
* weight of (number of set bits in) @relmap are mapped nowhere.
|
|
|
|
* In particular, if for all bits m set in @orig, m >= W, then
|
|
|
|
* @dst will end up empty. In situations where the possibility
|
|
|
|
* of such an empty result is not desired, one way to avoid it is
|
|
|
|
* to use the bitmap_fold() operator, below, to first fold the
|
|
|
|
* @orig bitmap over itself so that all its set bits x are in the
|
|
|
|
* range 0 <= x < W. The bitmap_fold() operator does this by
|
|
|
|
* setting the bit (m % W) in @dst, for each bit (m) set in @orig.
|
|
|
|
*
|
|
|
|
* Example [1] for bitmap_onto():
|
|
|
|
* Let's say @relmap has bits 30-39 set, and @orig has bits
|
|
|
|
* 1, 3, 5, 7, 9 and 11 set. Then on return from this routine,
|
|
|
|
* @dst will have bits 31, 33, 35, 37 and 39 set.
|
|
|
|
*
|
|
|
|
* When bit 0 is set in @orig, it means turn on the bit in
|
|
|
|
* @dst corresponding to whatever is the first bit (if any)
|
|
|
|
* that is turned on in @relmap. Since bit 0 was off in the
|
|
|
|
* above example, we leave off that bit (bit 30) in @dst.
|
|
|
|
*
|
|
|
|
* When bit 1 is set in @orig (as in the above example), it
|
|
|
|
* means turn on the bit in @dst corresponding to whatever
|
|
|
|
* is the second bit that is turned on in @relmap. The second
|
|
|
|
* bit in @relmap that was turned on in the above example was
|
|
|
|
* bit 31, so we turned on bit 31 in @dst.
|
|
|
|
*
|
|
|
|
* Similarly, we turned on bits 33, 35, 37 and 39 in @dst,
|
|
|
|
* because they were the 4th, 6th, 8th and 10th set bits
|
|
|
|
* set in @relmap, and the 4th, 6th, 8th and 10th bits of
|
|
|
|
* @orig (i.e. bits 3, 5, 7 and 9) were also set.
|
|
|
|
*
|
|
|
|
* When bit 11 is set in @orig, it means turn on the bit in
|
2011-03-31 01:57:33 +00:00
|
|
|
* @dst corresponding to whatever is the twelfth bit that is
|
mempolicy: add bitmap_onto() and bitmap_fold() operations
The following adds two more bitmap operators, bitmap_onto() and bitmap_fold(),
with the usual cpumask and nodemask wrappers.
The bitmap_onto() operator computes one bitmap relative to another. If the
n-th bit in the origin mask is set, then the m-th bit of the destination mask
will be set, where m is the position of the n-th set bit in the relative mask.
The bitmap_fold() operator folds a bitmap into a second that has bit m set iff
the input bitmap has some bit n set, where m == n mod sz, for the specified sz
value.
There are two substantive changes between this patch and its
predecessor bitmap_relative:
1) Renamed bitmap_relative() to be bitmap_onto().
2) Added bitmap_fold().
The essential motivation for bitmap_onto() is to provide a mechanism for
converting a cpuset-relative CPU or Node mask to an absolute mask. Cpuset
relative masks are written as if the current task were in a cpuset whose CPUs
or Nodes were just the consecutive ones numbered 0..N-1, for some N. The
bitmap_onto() operator is provided in anticipation of adding support for the
first such cpuset relative mask, by the mbind() and set_mempolicy() system
calls, using a planned flag of MPOL_F_RELATIVE_NODES. These bitmap operators
(and their nodemask wrappers, in particular) will be used in code that
converts the user specified cpuset relative memory policy to a specific system
node numbered policy, given the current mems_allowed of the tasks cpuset.
Such cpuset relative mempolicies will address two deficiencies
of the existing interface between cpusets and mempolicies:
1) A task cannot at present reliably establish a cpuset
relative mempolicy because there is an essential race
condition, in that the tasks cpuset may be changed in
between the time the task can query its cpuset placement,
and the time the task can issue the applicable mbind or
set_memplicy system call.
2) A task cannot at present establish what cpuset relative
mempolicy it would like to have, if it is in a smaller
cpuset than it might have mempolicy preferences for,
because the existing interface only allows specifying
mempolicies for nodes currently allowed by the cpuset.
Cpuset relative mempolicies are useful for tasks that don't distinguish
particularly between one CPU or Node and another, but only between how many of
each are allowed, and the proper placement of threads and memory pages on the
various CPUs and Nodes available.
The motivation for the added bitmap_fold() can be seen in the following
example.
Let's say an application has specified some mempolicies that presume 16 memory
nodes, including say a mempolicy that specified MPOL_F_RELATIVE_NODES (cpuset
relative) nodes 12-15. Then lets say that application is crammed into a
cpuset that only has 8 memory nodes, 0-7. If one just uses bitmap_onto(),
this mempolicy, mapped to that cpuset, would ignore the requested relative
nodes above 7, leaving it empty of nodes. That's not good; better to fold the
higher nodes down, so that some nodes are included in the resulting mapped
mempolicy. In this case, the mempolicy nodes 12-15 are taken modulo 8 (the
weight of the mems_allowed of the confining cpuset), resulting in a mempolicy
specifying nodes 4-7.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: <kosaki.motohiro@jp.fujitsu.com>
Cc: <ray-lk@madrabbit.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-28 09:12:29 +00:00
|
|
|
* turned on in @relmap. In the above example, there were
|
|
|
|
* only ten bits turned on in @relmap (30..39), so that bit
|
|
|
|
* 11 was set in @orig had no affect on @dst.
|
|
|
|
*
|
|
|
|
* Example [2] for bitmap_fold() + bitmap_onto():
|
2017-03-30 20:11:35 +00:00
|
|
|
* Let's say @relmap has these ten bits set::
|
|
|
|
*
|
mempolicy: add bitmap_onto() and bitmap_fold() operations
The following adds two more bitmap operators, bitmap_onto() and bitmap_fold(),
with the usual cpumask and nodemask wrappers.
The bitmap_onto() operator computes one bitmap relative to another. If the
n-th bit in the origin mask is set, then the m-th bit of the destination mask
will be set, where m is the position of the n-th set bit in the relative mask.
The bitmap_fold() operator folds a bitmap into a second that has bit m set iff
the input bitmap has some bit n set, where m == n mod sz, for the specified sz
value.
There are two substantive changes between this patch and its
predecessor bitmap_relative:
1) Renamed bitmap_relative() to be bitmap_onto().
2) Added bitmap_fold().
The essential motivation for bitmap_onto() is to provide a mechanism for
converting a cpuset-relative CPU or Node mask to an absolute mask. Cpuset
relative masks are written as if the current task were in a cpuset whose CPUs
or Nodes were just the consecutive ones numbered 0..N-1, for some N. The
bitmap_onto() operator is provided in anticipation of adding support for the
first such cpuset relative mask, by the mbind() and set_mempolicy() system
calls, using a planned flag of MPOL_F_RELATIVE_NODES. These bitmap operators
(and their nodemask wrappers, in particular) will be used in code that
converts the user specified cpuset relative memory policy to a specific system
node numbered policy, given the current mems_allowed of the tasks cpuset.
Such cpuset relative mempolicies will address two deficiencies
of the existing interface between cpusets and mempolicies:
1) A task cannot at present reliably establish a cpuset
relative mempolicy because there is an essential race
condition, in that the tasks cpuset may be changed in
between the time the task can query its cpuset placement,
and the time the task can issue the applicable mbind or
set_memplicy system call.
2) A task cannot at present establish what cpuset relative
mempolicy it would like to have, if it is in a smaller
cpuset than it might have mempolicy preferences for,
because the existing interface only allows specifying
mempolicies for nodes currently allowed by the cpuset.
Cpuset relative mempolicies are useful for tasks that don't distinguish
particularly between one CPU or Node and another, but only between how many of
each are allowed, and the proper placement of threads and memory pages on the
various CPUs and Nodes available.
The motivation for the added bitmap_fold() can be seen in the following
example.
Let's say an application has specified some mempolicies that presume 16 memory
nodes, including say a mempolicy that specified MPOL_F_RELATIVE_NODES (cpuset
relative) nodes 12-15. Then lets say that application is crammed into a
cpuset that only has 8 memory nodes, 0-7. If one just uses bitmap_onto(),
this mempolicy, mapped to that cpuset, would ignore the requested relative
nodes above 7, leaving it empty of nodes. That's not good; better to fold the
higher nodes down, so that some nodes are included in the resulting mapped
mempolicy. In this case, the mempolicy nodes 12-15 are taken modulo 8 (the
weight of the mems_allowed of the confining cpuset), resulting in a mempolicy
specifying nodes 4-7.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: <kosaki.motohiro@jp.fujitsu.com>
Cc: <ray-lk@madrabbit.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-28 09:12:29 +00:00
|
|
|
* 40 41 42 43 45 48 53 61 74 95
|
2017-03-30 20:11:35 +00:00
|
|
|
*
|
mempolicy: add bitmap_onto() and bitmap_fold() operations
The following adds two more bitmap operators, bitmap_onto() and bitmap_fold(),
with the usual cpumask and nodemask wrappers.
The bitmap_onto() operator computes one bitmap relative to another. If the
n-th bit in the origin mask is set, then the m-th bit of the destination mask
will be set, where m is the position of the n-th set bit in the relative mask.
The bitmap_fold() operator folds a bitmap into a second that has bit m set iff
the input bitmap has some bit n set, where m == n mod sz, for the specified sz
value.
There are two substantive changes between this patch and its
predecessor bitmap_relative:
1) Renamed bitmap_relative() to be bitmap_onto().
2) Added bitmap_fold().
The essential motivation for bitmap_onto() is to provide a mechanism for
converting a cpuset-relative CPU or Node mask to an absolute mask. Cpuset
relative masks are written as if the current task were in a cpuset whose CPUs
or Nodes were just the consecutive ones numbered 0..N-1, for some N. The
bitmap_onto() operator is provided in anticipation of adding support for the
first such cpuset relative mask, by the mbind() and set_mempolicy() system
calls, using a planned flag of MPOL_F_RELATIVE_NODES. These bitmap operators
(and their nodemask wrappers, in particular) will be used in code that
converts the user specified cpuset relative memory policy to a specific system
node numbered policy, given the current mems_allowed of the tasks cpuset.
Such cpuset relative mempolicies will address two deficiencies
of the existing interface between cpusets and mempolicies:
1) A task cannot at present reliably establish a cpuset
relative mempolicy because there is an essential race
condition, in that the tasks cpuset may be changed in
between the time the task can query its cpuset placement,
and the time the task can issue the applicable mbind or
set_memplicy system call.
2) A task cannot at present establish what cpuset relative
mempolicy it would like to have, if it is in a smaller
cpuset than it might have mempolicy preferences for,
because the existing interface only allows specifying
mempolicies for nodes currently allowed by the cpuset.
Cpuset relative mempolicies are useful for tasks that don't distinguish
particularly between one CPU or Node and another, but only between how many of
each are allowed, and the proper placement of threads and memory pages on the
various CPUs and Nodes available.
The motivation for the added bitmap_fold() can be seen in the following
example.
Let's say an application has specified some mempolicies that presume 16 memory
nodes, including say a mempolicy that specified MPOL_F_RELATIVE_NODES (cpuset
relative) nodes 12-15. Then lets say that application is crammed into a
cpuset that only has 8 memory nodes, 0-7. If one just uses bitmap_onto(),
this mempolicy, mapped to that cpuset, would ignore the requested relative
nodes above 7, leaving it empty of nodes. That's not good; better to fold the
higher nodes down, so that some nodes are included in the resulting mapped
mempolicy. In this case, the mempolicy nodes 12-15 are taken modulo 8 (the
weight of the mems_allowed of the confining cpuset), resulting in a mempolicy
specifying nodes 4-7.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: <kosaki.motohiro@jp.fujitsu.com>
Cc: <ray-lk@madrabbit.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-28 09:12:29 +00:00
|
|
|
* (for the curious, that's 40 plus the first ten terms of the
|
|
|
|
* Fibonacci sequence.)
|
|
|
|
*
|
|
|
|
* Further lets say we use the following code, invoking
|
|
|
|
* bitmap_fold() then bitmap_onto, as suggested above to
|
2017-03-30 20:11:35 +00:00
|
|
|
* avoid the possibility of an empty @dst result::
|
mempolicy: add bitmap_onto() and bitmap_fold() operations
The following adds two more bitmap operators, bitmap_onto() and bitmap_fold(),
with the usual cpumask and nodemask wrappers.
The bitmap_onto() operator computes one bitmap relative to another. If the
n-th bit in the origin mask is set, then the m-th bit of the destination mask
will be set, where m is the position of the n-th set bit in the relative mask.
The bitmap_fold() operator folds a bitmap into a second that has bit m set iff
the input bitmap has some bit n set, where m == n mod sz, for the specified sz
value.
There are two substantive changes between this patch and its
predecessor bitmap_relative:
1) Renamed bitmap_relative() to be bitmap_onto().
2) Added bitmap_fold().
The essential motivation for bitmap_onto() is to provide a mechanism for
converting a cpuset-relative CPU or Node mask to an absolute mask. Cpuset
relative masks are written as if the current task were in a cpuset whose CPUs
or Nodes were just the consecutive ones numbered 0..N-1, for some N. The
bitmap_onto() operator is provided in anticipation of adding support for the
first such cpuset relative mask, by the mbind() and set_mempolicy() system
calls, using a planned flag of MPOL_F_RELATIVE_NODES. These bitmap operators
(and their nodemask wrappers, in particular) will be used in code that
converts the user specified cpuset relative memory policy to a specific system
node numbered policy, given the current mems_allowed of the tasks cpuset.
Such cpuset relative mempolicies will address two deficiencies
of the existing interface between cpusets and mempolicies:
1) A task cannot at present reliably establish a cpuset
relative mempolicy because there is an essential race
condition, in that the tasks cpuset may be changed in
between the time the task can query its cpuset placement,
and the time the task can issue the applicable mbind or
set_memplicy system call.
2) A task cannot at present establish what cpuset relative
mempolicy it would like to have, if it is in a smaller
cpuset than it might have mempolicy preferences for,
because the existing interface only allows specifying
mempolicies for nodes currently allowed by the cpuset.
Cpuset relative mempolicies are useful for tasks that don't distinguish
particularly between one CPU or Node and another, but only between how many of
each are allowed, and the proper placement of threads and memory pages on the
various CPUs and Nodes available.
The motivation for the added bitmap_fold() can be seen in the following
example.
Let's say an application has specified some mempolicies that presume 16 memory
nodes, including say a mempolicy that specified MPOL_F_RELATIVE_NODES (cpuset
relative) nodes 12-15. Then lets say that application is crammed into a
cpuset that only has 8 memory nodes, 0-7. If one just uses bitmap_onto(),
this mempolicy, mapped to that cpuset, would ignore the requested relative
nodes above 7, leaving it empty of nodes. That's not good; better to fold the
higher nodes down, so that some nodes are included in the resulting mapped
mempolicy. In this case, the mempolicy nodes 12-15 are taken modulo 8 (the
weight of the mems_allowed of the confining cpuset), resulting in a mempolicy
specifying nodes 4-7.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: <kosaki.motohiro@jp.fujitsu.com>
Cc: <ray-lk@madrabbit.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-28 09:12:29 +00:00
|
|
|
*
|
|
|
|
* unsigned long *tmp; // a temporary bitmap's bits
|
|
|
|
*
|
|
|
|
* bitmap_fold(tmp, orig, bitmap_weight(relmap, bits), bits);
|
|
|
|
* bitmap_onto(dst, tmp, relmap, bits);
|
|
|
|
*
|
|
|
|
* Then this table shows what various values of @dst would be, for
|
|
|
|
* various @orig's. I list the zero-based positions of each set bit.
|
|
|
|
* The tmp column shows the intermediate result, as computed by
|
|
|
|
* using bitmap_fold() to fold the @orig bitmap modulo ten
|
2017-03-30 20:11:35 +00:00
|
|
|
* (the weight of @relmap):
|
mempolicy: add bitmap_onto() and bitmap_fold() operations
The following adds two more bitmap operators, bitmap_onto() and bitmap_fold(),
with the usual cpumask and nodemask wrappers.
The bitmap_onto() operator computes one bitmap relative to another. If the
n-th bit in the origin mask is set, then the m-th bit of the destination mask
will be set, where m is the position of the n-th set bit in the relative mask.
The bitmap_fold() operator folds a bitmap into a second that has bit m set iff
the input bitmap has some bit n set, where m == n mod sz, for the specified sz
value.
There are two substantive changes between this patch and its
predecessor bitmap_relative:
1) Renamed bitmap_relative() to be bitmap_onto().
2) Added bitmap_fold().
The essential motivation for bitmap_onto() is to provide a mechanism for
converting a cpuset-relative CPU or Node mask to an absolute mask. Cpuset
relative masks are written as if the current task were in a cpuset whose CPUs
or Nodes were just the consecutive ones numbered 0..N-1, for some N. The
bitmap_onto() operator is provided in anticipation of adding support for the
first such cpuset relative mask, by the mbind() and set_mempolicy() system
calls, using a planned flag of MPOL_F_RELATIVE_NODES. These bitmap operators
(and their nodemask wrappers, in particular) will be used in code that
converts the user specified cpuset relative memory policy to a specific system
node numbered policy, given the current mems_allowed of the tasks cpuset.
Such cpuset relative mempolicies will address two deficiencies
of the existing interface between cpusets and mempolicies:
1) A task cannot at present reliably establish a cpuset
relative mempolicy because there is an essential race
condition, in that the tasks cpuset may be changed in
between the time the task can query its cpuset placement,
and the time the task can issue the applicable mbind or
set_memplicy system call.
2) A task cannot at present establish what cpuset relative
mempolicy it would like to have, if it is in a smaller
cpuset than it might have mempolicy preferences for,
because the existing interface only allows specifying
mempolicies for nodes currently allowed by the cpuset.
Cpuset relative mempolicies are useful for tasks that don't distinguish
particularly between one CPU or Node and another, but only between how many of
each are allowed, and the proper placement of threads and memory pages on the
various CPUs and Nodes available.
The motivation for the added bitmap_fold() can be seen in the following
example.
Let's say an application has specified some mempolicies that presume 16 memory
nodes, including say a mempolicy that specified MPOL_F_RELATIVE_NODES (cpuset
relative) nodes 12-15. Then lets say that application is crammed into a
cpuset that only has 8 memory nodes, 0-7. If one just uses bitmap_onto(),
this mempolicy, mapped to that cpuset, would ignore the requested relative
nodes above 7, leaving it empty of nodes. That's not good; better to fold the
higher nodes down, so that some nodes are included in the resulting mapped
mempolicy. In this case, the mempolicy nodes 12-15 are taken modulo 8 (the
weight of the mems_allowed of the confining cpuset), resulting in a mempolicy
specifying nodes 4-7.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: <kosaki.motohiro@jp.fujitsu.com>
Cc: <ray-lk@madrabbit.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-28 09:12:29 +00:00
|
|
|
*
|
2017-03-30 20:11:35 +00:00
|
|
|
* =============== ============== =================
|
mempolicy: add bitmap_onto() and bitmap_fold() operations
The following adds two more bitmap operators, bitmap_onto() and bitmap_fold(),
with the usual cpumask and nodemask wrappers.
The bitmap_onto() operator computes one bitmap relative to another. If the
n-th bit in the origin mask is set, then the m-th bit of the destination mask
will be set, where m is the position of the n-th set bit in the relative mask.
The bitmap_fold() operator folds a bitmap into a second that has bit m set iff
the input bitmap has some bit n set, where m == n mod sz, for the specified sz
value.
There are two substantive changes between this patch and its
predecessor bitmap_relative:
1) Renamed bitmap_relative() to be bitmap_onto().
2) Added bitmap_fold().
The essential motivation for bitmap_onto() is to provide a mechanism for
converting a cpuset-relative CPU or Node mask to an absolute mask. Cpuset
relative masks are written as if the current task were in a cpuset whose CPUs
or Nodes were just the consecutive ones numbered 0..N-1, for some N. The
bitmap_onto() operator is provided in anticipation of adding support for the
first such cpuset relative mask, by the mbind() and set_mempolicy() system
calls, using a planned flag of MPOL_F_RELATIVE_NODES. These bitmap operators
(and their nodemask wrappers, in particular) will be used in code that
converts the user specified cpuset relative memory policy to a specific system
node numbered policy, given the current mems_allowed of the tasks cpuset.
Such cpuset relative mempolicies will address two deficiencies
of the existing interface between cpusets and mempolicies:
1) A task cannot at present reliably establish a cpuset
relative mempolicy because there is an essential race
condition, in that the tasks cpuset may be changed in
between the time the task can query its cpuset placement,
and the time the task can issue the applicable mbind or
set_memplicy system call.
2) A task cannot at present establish what cpuset relative
mempolicy it would like to have, if it is in a smaller
cpuset than it might have mempolicy preferences for,
because the existing interface only allows specifying
mempolicies for nodes currently allowed by the cpuset.
Cpuset relative mempolicies are useful for tasks that don't distinguish
particularly between one CPU or Node and another, but only between how many of
each are allowed, and the proper placement of threads and memory pages on the
various CPUs and Nodes available.
The motivation for the added bitmap_fold() can be seen in the following
example.
Let's say an application has specified some mempolicies that presume 16 memory
nodes, including say a mempolicy that specified MPOL_F_RELATIVE_NODES (cpuset
relative) nodes 12-15. Then lets say that application is crammed into a
cpuset that only has 8 memory nodes, 0-7. If one just uses bitmap_onto(),
this mempolicy, mapped to that cpuset, would ignore the requested relative
nodes above 7, leaving it empty of nodes. That's not good; better to fold the
higher nodes down, so that some nodes are included in the resulting mapped
mempolicy. In this case, the mempolicy nodes 12-15 are taken modulo 8 (the
weight of the mems_allowed of the confining cpuset), resulting in a mempolicy
specifying nodes 4-7.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: <kosaki.motohiro@jp.fujitsu.com>
Cc: <ray-lk@madrabbit.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-28 09:12:29 +00:00
|
|
|
* @orig tmp @dst
|
|
|
|
* 0 0 40
|
|
|
|
* 1 1 41
|
|
|
|
* 9 9 95
|
2017-03-30 20:11:35 +00:00
|
|
|
* 10 0 40 [#f1]_
|
mempolicy: add bitmap_onto() and bitmap_fold() operations
The following adds two more bitmap operators, bitmap_onto() and bitmap_fold(),
with the usual cpumask and nodemask wrappers.
The bitmap_onto() operator computes one bitmap relative to another. If the
n-th bit in the origin mask is set, then the m-th bit of the destination mask
will be set, where m is the position of the n-th set bit in the relative mask.
The bitmap_fold() operator folds a bitmap into a second that has bit m set iff
the input bitmap has some bit n set, where m == n mod sz, for the specified sz
value.
There are two substantive changes between this patch and its
predecessor bitmap_relative:
1) Renamed bitmap_relative() to be bitmap_onto().
2) Added bitmap_fold().
The essential motivation for bitmap_onto() is to provide a mechanism for
converting a cpuset-relative CPU or Node mask to an absolute mask. Cpuset
relative masks are written as if the current task were in a cpuset whose CPUs
or Nodes were just the consecutive ones numbered 0..N-1, for some N. The
bitmap_onto() operator is provided in anticipation of adding support for the
first such cpuset relative mask, by the mbind() and set_mempolicy() system
calls, using a planned flag of MPOL_F_RELATIVE_NODES. These bitmap operators
(and their nodemask wrappers, in particular) will be used in code that
converts the user specified cpuset relative memory policy to a specific system
node numbered policy, given the current mems_allowed of the tasks cpuset.
Such cpuset relative mempolicies will address two deficiencies
of the existing interface between cpusets and mempolicies:
1) A task cannot at present reliably establish a cpuset
relative mempolicy because there is an essential race
condition, in that the tasks cpuset may be changed in
between the time the task can query its cpuset placement,
and the time the task can issue the applicable mbind or
set_memplicy system call.
2) A task cannot at present establish what cpuset relative
mempolicy it would like to have, if it is in a smaller
cpuset than it might have mempolicy preferences for,
because the existing interface only allows specifying
mempolicies for nodes currently allowed by the cpuset.
Cpuset relative mempolicies are useful for tasks that don't distinguish
particularly between one CPU or Node and another, but only between how many of
each are allowed, and the proper placement of threads and memory pages on the
various CPUs and Nodes available.
The motivation for the added bitmap_fold() can be seen in the following
example.
Let's say an application has specified some mempolicies that presume 16 memory
nodes, including say a mempolicy that specified MPOL_F_RELATIVE_NODES (cpuset
relative) nodes 12-15. Then lets say that application is crammed into a
cpuset that only has 8 memory nodes, 0-7. If one just uses bitmap_onto(),
this mempolicy, mapped to that cpuset, would ignore the requested relative
nodes above 7, leaving it empty of nodes. That's not good; better to fold the
higher nodes down, so that some nodes are included in the resulting mapped
mempolicy. In this case, the mempolicy nodes 12-15 are taken modulo 8 (the
weight of the mems_allowed of the confining cpuset), resulting in a mempolicy
specifying nodes 4-7.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: <kosaki.motohiro@jp.fujitsu.com>
Cc: <ray-lk@madrabbit.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-28 09:12:29 +00:00
|
|
|
* 1 3 5 7 1 3 5 7 41 43 48 61
|
|
|
|
* 0 1 2 3 4 0 1 2 3 4 40 41 42 43 45
|
|
|
|
* 0 9 18 27 0 9 8 7 40 61 74 95
|
|
|
|
* 0 10 20 30 0 40
|
|
|
|
* 0 11 22 33 0 1 2 3 40 41 42 43
|
|
|
|
* 0 12 24 36 0 2 4 6 40 42 45 53
|
2017-03-30 20:11:35 +00:00
|
|
|
* 78 102 211 1 2 8 41 42 74 [#f1]_
|
|
|
|
* =============== ============== =================
|
|
|
|
*
|
|
|
|
* .. [#f1]
|
mempolicy: add bitmap_onto() and bitmap_fold() operations
The following adds two more bitmap operators, bitmap_onto() and bitmap_fold(),
with the usual cpumask and nodemask wrappers.
The bitmap_onto() operator computes one bitmap relative to another. If the
n-th bit in the origin mask is set, then the m-th bit of the destination mask
will be set, where m is the position of the n-th set bit in the relative mask.
The bitmap_fold() operator folds a bitmap into a second that has bit m set iff
the input bitmap has some bit n set, where m == n mod sz, for the specified sz
value.
There are two substantive changes between this patch and its
predecessor bitmap_relative:
1) Renamed bitmap_relative() to be bitmap_onto().
2) Added bitmap_fold().
The essential motivation for bitmap_onto() is to provide a mechanism for
converting a cpuset-relative CPU or Node mask to an absolute mask. Cpuset
relative masks are written as if the current task were in a cpuset whose CPUs
or Nodes were just the consecutive ones numbered 0..N-1, for some N. The
bitmap_onto() operator is provided in anticipation of adding support for the
first such cpuset relative mask, by the mbind() and set_mempolicy() system
calls, using a planned flag of MPOL_F_RELATIVE_NODES. These bitmap operators
(and their nodemask wrappers, in particular) will be used in code that
converts the user specified cpuset relative memory policy to a specific system
node numbered policy, given the current mems_allowed of the tasks cpuset.
Such cpuset relative mempolicies will address two deficiencies
of the existing interface between cpusets and mempolicies:
1) A task cannot at present reliably establish a cpuset
relative mempolicy because there is an essential race
condition, in that the tasks cpuset may be changed in
between the time the task can query its cpuset placement,
and the time the task can issue the applicable mbind or
set_memplicy system call.
2) A task cannot at present establish what cpuset relative
mempolicy it would like to have, if it is in a smaller
cpuset than it might have mempolicy preferences for,
because the existing interface only allows specifying
mempolicies for nodes currently allowed by the cpuset.
Cpuset relative mempolicies are useful for tasks that don't distinguish
particularly between one CPU or Node and another, but only between how many of
each are allowed, and the proper placement of threads and memory pages on the
various CPUs and Nodes available.
The motivation for the added bitmap_fold() can be seen in the following
example.
Let's say an application has specified some mempolicies that presume 16 memory
nodes, including say a mempolicy that specified MPOL_F_RELATIVE_NODES (cpuset
relative) nodes 12-15. Then lets say that application is crammed into a
cpuset that only has 8 memory nodes, 0-7. If one just uses bitmap_onto(),
this mempolicy, mapped to that cpuset, would ignore the requested relative
nodes above 7, leaving it empty of nodes. That's not good; better to fold the
higher nodes down, so that some nodes are included in the resulting mapped
mempolicy. In this case, the mempolicy nodes 12-15 are taken modulo 8 (the
weight of the mems_allowed of the confining cpuset), resulting in a mempolicy
specifying nodes 4-7.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: <kosaki.motohiro@jp.fujitsu.com>
Cc: <ray-lk@madrabbit.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-28 09:12:29 +00:00
|
|
|
*
|
2017-03-30 20:11:35 +00:00
|
|
|
* For these marked lines, if we hadn't first done bitmap_fold()
|
mempolicy: add bitmap_onto() and bitmap_fold() operations
The following adds two more bitmap operators, bitmap_onto() and bitmap_fold(),
with the usual cpumask and nodemask wrappers.
The bitmap_onto() operator computes one bitmap relative to another. If the
n-th bit in the origin mask is set, then the m-th bit of the destination mask
will be set, where m is the position of the n-th set bit in the relative mask.
The bitmap_fold() operator folds a bitmap into a second that has bit m set iff
the input bitmap has some bit n set, where m == n mod sz, for the specified sz
value.
There are two substantive changes between this patch and its
predecessor bitmap_relative:
1) Renamed bitmap_relative() to be bitmap_onto().
2) Added bitmap_fold().
The essential motivation for bitmap_onto() is to provide a mechanism for
converting a cpuset-relative CPU or Node mask to an absolute mask. Cpuset
relative masks are written as if the current task were in a cpuset whose CPUs
or Nodes were just the consecutive ones numbered 0..N-1, for some N. The
bitmap_onto() operator is provided in anticipation of adding support for the
first such cpuset relative mask, by the mbind() and set_mempolicy() system
calls, using a planned flag of MPOL_F_RELATIVE_NODES. These bitmap operators
(and their nodemask wrappers, in particular) will be used in code that
converts the user specified cpuset relative memory policy to a specific system
node numbered policy, given the current mems_allowed of the tasks cpuset.
Such cpuset relative mempolicies will address two deficiencies
of the existing interface between cpusets and mempolicies:
1) A task cannot at present reliably establish a cpuset
relative mempolicy because there is an essential race
condition, in that the tasks cpuset may be changed in
between the time the task can query its cpuset placement,
and the time the task can issue the applicable mbind or
set_memplicy system call.
2) A task cannot at present establish what cpuset relative
mempolicy it would like to have, if it is in a smaller
cpuset than it might have mempolicy preferences for,
because the existing interface only allows specifying
mempolicies for nodes currently allowed by the cpuset.
Cpuset relative mempolicies are useful for tasks that don't distinguish
particularly between one CPU or Node and another, but only between how many of
each are allowed, and the proper placement of threads and memory pages on the
various CPUs and Nodes available.
The motivation for the added bitmap_fold() can be seen in the following
example.
Let's say an application has specified some mempolicies that presume 16 memory
nodes, including say a mempolicy that specified MPOL_F_RELATIVE_NODES (cpuset
relative) nodes 12-15. Then lets say that application is crammed into a
cpuset that only has 8 memory nodes, 0-7. If one just uses bitmap_onto(),
this mempolicy, mapped to that cpuset, would ignore the requested relative
nodes above 7, leaving it empty of nodes. That's not good; better to fold the
higher nodes down, so that some nodes are included in the resulting mapped
mempolicy. In this case, the mempolicy nodes 12-15 are taken modulo 8 (the
weight of the mems_allowed of the confining cpuset), resulting in a mempolicy
specifying nodes 4-7.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: <kosaki.motohiro@jp.fujitsu.com>
Cc: <ray-lk@madrabbit.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-28 09:12:29 +00:00
|
|
|
* into tmp, then the @dst result would have been empty.
|
|
|
|
*
|
|
|
|
* If either of @orig or @relmap is empty (no set bits), then @dst
|
|
|
|
* will be returned empty.
|
|
|
|
*
|
|
|
|
* If (as explained above) the only set bits in @orig are in positions
|
|
|
|
* m where m >= W, (where W is the weight of @relmap) then @dst will
|
|
|
|
* once again be returned empty.
|
|
|
|
*
|
|
|
|
* All bits in @dst not set by the above rule are cleared.
|
|
|
|
*/
|
|
|
|
void bitmap_onto(unsigned long *dst, const unsigned long *orig,
|
2015-02-12 23:02:01 +00:00
|
|
|
const unsigned long *relmap, unsigned int bits)
|
mempolicy: add bitmap_onto() and bitmap_fold() operations
The following adds two more bitmap operators, bitmap_onto() and bitmap_fold(),
with the usual cpumask and nodemask wrappers.
The bitmap_onto() operator computes one bitmap relative to another. If the
n-th bit in the origin mask is set, then the m-th bit of the destination mask
will be set, where m is the position of the n-th set bit in the relative mask.
The bitmap_fold() operator folds a bitmap into a second that has bit m set iff
the input bitmap has some bit n set, where m == n mod sz, for the specified sz
value.
There are two substantive changes between this patch and its
predecessor bitmap_relative:
1) Renamed bitmap_relative() to be bitmap_onto().
2) Added bitmap_fold().
The essential motivation for bitmap_onto() is to provide a mechanism for
converting a cpuset-relative CPU or Node mask to an absolute mask. Cpuset
relative masks are written as if the current task were in a cpuset whose CPUs
or Nodes were just the consecutive ones numbered 0..N-1, for some N. The
bitmap_onto() operator is provided in anticipation of adding support for the
first such cpuset relative mask, by the mbind() and set_mempolicy() system
calls, using a planned flag of MPOL_F_RELATIVE_NODES. These bitmap operators
(and their nodemask wrappers, in particular) will be used in code that
converts the user specified cpuset relative memory policy to a specific system
node numbered policy, given the current mems_allowed of the tasks cpuset.
Such cpuset relative mempolicies will address two deficiencies
of the existing interface between cpusets and mempolicies:
1) A task cannot at present reliably establish a cpuset
relative mempolicy because there is an essential race
condition, in that the tasks cpuset may be changed in
between the time the task can query its cpuset placement,
and the time the task can issue the applicable mbind or
set_memplicy system call.
2) A task cannot at present establish what cpuset relative
mempolicy it would like to have, if it is in a smaller
cpuset than it might have mempolicy preferences for,
because the existing interface only allows specifying
mempolicies for nodes currently allowed by the cpuset.
Cpuset relative mempolicies are useful for tasks that don't distinguish
particularly between one CPU or Node and another, but only between how many of
each are allowed, and the proper placement of threads and memory pages on the
various CPUs and Nodes available.
The motivation for the added bitmap_fold() can be seen in the following
example.
Let's say an application has specified some mempolicies that presume 16 memory
nodes, including say a mempolicy that specified MPOL_F_RELATIVE_NODES (cpuset
relative) nodes 12-15. Then lets say that application is crammed into a
cpuset that only has 8 memory nodes, 0-7. If one just uses bitmap_onto(),
this mempolicy, mapped to that cpuset, would ignore the requested relative
nodes above 7, leaving it empty of nodes. That's not good; better to fold the
higher nodes down, so that some nodes are included in the resulting mapped
mempolicy. In this case, the mempolicy nodes 12-15 are taken modulo 8 (the
weight of the mems_allowed of the confining cpuset), resulting in a mempolicy
specifying nodes 4-7.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: <kosaki.motohiro@jp.fujitsu.com>
Cc: <ray-lk@madrabbit.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-28 09:12:29 +00:00
|
|
|
{
|
2015-02-12 23:02:01 +00:00
|
|
|
unsigned int n, m; /* same meaning as in above comment */
|
mempolicy: add bitmap_onto() and bitmap_fold() operations
The following adds two more bitmap operators, bitmap_onto() and bitmap_fold(),
with the usual cpumask and nodemask wrappers.
The bitmap_onto() operator computes one bitmap relative to another. If the
n-th bit in the origin mask is set, then the m-th bit of the destination mask
will be set, where m is the position of the n-th set bit in the relative mask.
The bitmap_fold() operator folds a bitmap into a second that has bit m set iff
the input bitmap has some bit n set, where m == n mod sz, for the specified sz
value.
There are two substantive changes between this patch and its
predecessor bitmap_relative:
1) Renamed bitmap_relative() to be bitmap_onto().
2) Added bitmap_fold().
The essential motivation for bitmap_onto() is to provide a mechanism for
converting a cpuset-relative CPU or Node mask to an absolute mask. Cpuset
relative masks are written as if the current task were in a cpuset whose CPUs
or Nodes were just the consecutive ones numbered 0..N-1, for some N. The
bitmap_onto() operator is provided in anticipation of adding support for the
first such cpuset relative mask, by the mbind() and set_mempolicy() system
calls, using a planned flag of MPOL_F_RELATIVE_NODES. These bitmap operators
(and their nodemask wrappers, in particular) will be used in code that
converts the user specified cpuset relative memory policy to a specific system
node numbered policy, given the current mems_allowed of the tasks cpuset.
Such cpuset relative mempolicies will address two deficiencies
of the existing interface between cpusets and mempolicies:
1) A task cannot at present reliably establish a cpuset
relative mempolicy because there is an essential race
condition, in that the tasks cpuset may be changed in
between the time the task can query its cpuset placement,
and the time the task can issue the applicable mbind or
set_memplicy system call.
2) A task cannot at present establish what cpuset relative
mempolicy it would like to have, if it is in a smaller
cpuset than it might have mempolicy preferences for,
because the existing interface only allows specifying
mempolicies for nodes currently allowed by the cpuset.
Cpuset relative mempolicies are useful for tasks that don't distinguish
particularly between one CPU or Node and another, but only between how many of
each are allowed, and the proper placement of threads and memory pages on the
various CPUs and Nodes available.
The motivation for the added bitmap_fold() can be seen in the following
example.
Let's say an application has specified some mempolicies that presume 16 memory
nodes, including say a mempolicy that specified MPOL_F_RELATIVE_NODES (cpuset
relative) nodes 12-15. Then lets say that application is crammed into a
cpuset that only has 8 memory nodes, 0-7. If one just uses bitmap_onto(),
this mempolicy, mapped to that cpuset, would ignore the requested relative
nodes above 7, leaving it empty of nodes. That's not good; better to fold the
higher nodes down, so that some nodes are included in the resulting mapped
mempolicy. In this case, the mempolicy nodes 12-15 are taken modulo 8 (the
weight of the mems_allowed of the confining cpuset), resulting in a mempolicy
specifying nodes 4-7.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: <kosaki.motohiro@jp.fujitsu.com>
Cc: <ray-lk@madrabbit.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-28 09:12:29 +00:00
|
|
|
|
|
|
|
if (dst == orig) /* following doesn't handle inplace mappings */
|
|
|
|
return;
|
|
|
|
bitmap_zero(dst, bits);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The following code is a more efficient, but less
|
|
|
|
* obvious, equivalent to the loop:
|
|
|
|
* for (m = 0; m < bitmap_weight(relmap, bits); m++) {
|
2022-09-18 03:07:15 +00:00
|
|
|
* n = find_nth_bit(orig, bits, m);
|
mempolicy: add bitmap_onto() and bitmap_fold() operations
The following adds two more bitmap operators, bitmap_onto() and bitmap_fold(),
with the usual cpumask and nodemask wrappers.
The bitmap_onto() operator computes one bitmap relative to another. If the
n-th bit in the origin mask is set, then the m-th bit of the destination mask
will be set, where m is the position of the n-th set bit in the relative mask.
The bitmap_fold() operator folds a bitmap into a second that has bit m set iff
the input bitmap has some bit n set, where m == n mod sz, for the specified sz
value.
There are two substantive changes between this patch and its
predecessor bitmap_relative:
1) Renamed bitmap_relative() to be bitmap_onto().
2) Added bitmap_fold().
The essential motivation for bitmap_onto() is to provide a mechanism for
converting a cpuset-relative CPU or Node mask to an absolute mask. Cpuset
relative masks are written as if the current task were in a cpuset whose CPUs
or Nodes were just the consecutive ones numbered 0..N-1, for some N. The
bitmap_onto() operator is provided in anticipation of adding support for the
first such cpuset relative mask, by the mbind() and set_mempolicy() system
calls, using a planned flag of MPOL_F_RELATIVE_NODES. These bitmap operators
(and their nodemask wrappers, in particular) will be used in code that
converts the user specified cpuset relative memory policy to a specific system
node numbered policy, given the current mems_allowed of the tasks cpuset.
Such cpuset relative mempolicies will address two deficiencies
of the existing interface between cpusets and mempolicies:
1) A task cannot at present reliably establish a cpuset
relative mempolicy because there is an essential race
condition, in that the tasks cpuset may be changed in
between the time the task can query its cpuset placement,
and the time the task can issue the applicable mbind or
set_memplicy system call.
2) A task cannot at present establish what cpuset relative
mempolicy it would like to have, if it is in a smaller
cpuset than it might have mempolicy preferences for,
because the existing interface only allows specifying
mempolicies for nodes currently allowed by the cpuset.
Cpuset relative mempolicies are useful for tasks that don't distinguish
particularly between one CPU or Node and another, but only between how many of
each are allowed, and the proper placement of threads and memory pages on the
various CPUs and Nodes available.
The motivation for the added bitmap_fold() can be seen in the following
example.
Let's say an application has specified some mempolicies that presume 16 memory
nodes, including say a mempolicy that specified MPOL_F_RELATIVE_NODES (cpuset
relative) nodes 12-15. Then lets say that application is crammed into a
cpuset that only has 8 memory nodes, 0-7. If one just uses bitmap_onto(),
this mempolicy, mapped to that cpuset, would ignore the requested relative
nodes above 7, leaving it empty of nodes. That's not good; better to fold the
higher nodes down, so that some nodes are included in the resulting mapped
mempolicy. In this case, the mempolicy nodes 12-15 are taken modulo 8 (the
weight of the mems_allowed of the confining cpuset), resulting in a mempolicy
specifying nodes 4-7.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: <kosaki.motohiro@jp.fujitsu.com>
Cc: <ray-lk@madrabbit.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-28 09:12:29 +00:00
|
|
|
* if (test_bit(m, orig))
|
|
|
|
* set_bit(n, dst);
|
|
|
|
* }
|
|
|
|
*/
|
|
|
|
|
|
|
|
m = 0;
|
2010-03-05 21:43:18 +00:00
|
|
|
for_each_set_bit(n, relmap, bits) {
|
mempolicy: add bitmap_onto() and bitmap_fold() operations
The following adds two more bitmap operators, bitmap_onto() and bitmap_fold(),
with the usual cpumask and nodemask wrappers.
The bitmap_onto() operator computes one bitmap relative to another. If the
n-th bit in the origin mask is set, then the m-th bit of the destination mask
will be set, where m is the position of the n-th set bit in the relative mask.
The bitmap_fold() operator folds a bitmap into a second that has bit m set iff
the input bitmap has some bit n set, where m == n mod sz, for the specified sz
value.
There are two substantive changes between this patch and its
predecessor bitmap_relative:
1) Renamed bitmap_relative() to be bitmap_onto().
2) Added bitmap_fold().
The essential motivation for bitmap_onto() is to provide a mechanism for
converting a cpuset-relative CPU or Node mask to an absolute mask. Cpuset
relative masks are written as if the current task were in a cpuset whose CPUs
or Nodes were just the consecutive ones numbered 0..N-1, for some N. The
bitmap_onto() operator is provided in anticipation of adding support for the
first such cpuset relative mask, by the mbind() and set_mempolicy() system
calls, using a planned flag of MPOL_F_RELATIVE_NODES. These bitmap operators
(and their nodemask wrappers, in particular) will be used in code that
converts the user specified cpuset relative memory policy to a specific system
node numbered policy, given the current mems_allowed of the tasks cpuset.
Such cpuset relative mempolicies will address two deficiencies
of the existing interface between cpusets and mempolicies:
1) A task cannot at present reliably establish a cpuset
relative mempolicy because there is an essential race
condition, in that the tasks cpuset may be changed in
between the time the task can query its cpuset placement,
and the time the task can issue the applicable mbind or
set_memplicy system call.
2) A task cannot at present establish what cpuset relative
mempolicy it would like to have, if it is in a smaller
cpuset than it might have mempolicy preferences for,
because the existing interface only allows specifying
mempolicies for nodes currently allowed by the cpuset.
Cpuset relative mempolicies are useful for tasks that don't distinguish
particularly between one CPU or Node and another, but only between how many of
each are allowed, and the proper placement of threads and memory pages on the
various CPUs and Nodes available.
The motivation for the added bitmap_fold() can be seen in the following
example.
Let's say an application has specified some mempolicies that presume 16 memory
nodes, including say a mempolicy that specified MPOL_F_RELATIVE_NODES (cpuset
relative) nodes 12-15. Then lets say that application is crammed into a
cpuset that only has 8 memory nodes, 0-7. If one just uses bitmap_onto(),
this mempolicy, mapped to that cpuset, would ignore the requested relative
nodes above 7, leaving it empty of nodes. That's not good; better to fold the
higher nodes down, so that some nodes are included in the resulting mapped
mempolicy. In this case, the mempolicy nodes 12-15 are taken modulo 8 (the
weight of the mems_allowed of the confining cpuset), resulting in a mempolicy
specifying nodes 4-7.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: <kosaki.motohiro@jp.fujitsu.com>
Cc: <ray-lk@madrabbit.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-28 09:12:29 +00:00
|
|
|
/* m == bitmap_pos_to_ord(relmap, n, bits) */
|
|
|
|
if (test_bit(m, orig))
|
|
|
|
set_bit(n, dst);
|
|
|
|
m++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* bitmap_fold - fold larger bitmap into smaller, modulo specified size
|
|
|
|
* @dst: resulting smaller bitmap
|
|
|
|
* @orig: original larger bitmap
|
|
|
|
* @sz: specified size
|
2015-02-12 23:02:04 +00:00
|
|
|
* @nbits: number of bits in each of these bitmaps
|
mempolicy: add bitmap_onto() and bitmap_fold() operations
The following adds two more bitmap operators, bitmap_onto() and bitmap_fold(),
with the usual cpumask and nodemask wrappers.
The bitmap_onto() operator computes one bitmap relative to another. If the
n-th bit in the origin mask is set, then the m-th bit of the destination mask
will be set, where m is the position of the n-th set bit in the relative mask.
The bitmap_fold() operator folds a bitmap into a second that has bit m set iff
the input bitmap has some bit n set, where m == n mod sz, for the specified sz
value.
There are two substantive changes between this patch and its
predecessor bitmap_relative:
1) Renamed bitmap_relative() to be bitmap_onto().
2) Added bitmap_fold().
The essential motivation for bitmap_onto() is to provide a mechanism for
converting a cpuset-relative CPU or Node mask to an absolute mask. Cpuset
relative masks are written as if the current task were in a cpuset whose CPUs
or Nodes were just the consecutive ones numbered 0..N-1, for some N. The
bitmap_onto() operator is provided in anticipation of adding support for the
first such cpuset relative mask, by the mbind() and set_mempolicy() system
calls, using a planned flag of MPOL_F_RELATIVE_NODES. These bitmap operators
(and their nodemask wrappers, in particular) will be used in code that
converts the user specified cpuset relative memory policy to a specific system
node numbered policy, given the current mems_allowed of the tasks cpuset.
Such cpuset relative mempolicies will address two deficiencies
of the existing interface between cpusets and mempolicies:
1) A task cannot at present reliably establish a cpuset
relative mempolicy because there is an essential race
condition, in that the tasks cpuset may be changed in
between the time the task can query its cpuset placement,
and the time the task can issue the applicable mbind or
set_memplicy system call.
2) A task cannot at present establish what cpuset relative
mempolicy it would like to have, if it is in a smaller
cpuset than it might have mempolicy preferences for,
because the existing interface only allows specifying
mempolicies for nodes currently allowed by the cpuset.
Cpuset relative mempolicies are useful for tasks that don't distinguish
particularly between one CPU or Node and another, but only between how many of
each are allowed, and the proper placement of threads and memory pages on the
various CPUs and Nodes available.
The motivation for the added bitmap_fold() can be seen in the following
example.
Let's say an application has specified some mempolicies that presume 16 memory
nodes, including say a mempolicy that specified MPOL_F_RELATIVE_NODES (cpuset
relative) nodes 12-15. Then lets say that application is crammed into a
cpuset that only has 8 memory nodes, 0-7. If one just uses bitmap_onto(),
this mempolicy, mapped to that cpuset, would ignore the requested relative
nodes above 7, leaving it empty of nodes. That's not good; better to fold the
higher nodes down, so that some nodes are included in the resulting mapped
mempolicy. In this case, the mempolicy nodes 12-15 are taken modulo 8 (the
weight of the mems_allowed of the confining cpuset), resulting in a mempolicy
specifying nodes 4-7.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: <kosaki.motohiro@jp.fujitsu.com>
Cc: <ray-lk@madrabbit.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-28 09:12:29 +00:00
|
|
|
*
|
|
|
|
* For each bit oldbit in @orig, set bit oldbit mod @sz in @dst.
|
|
|
|
* Clear all other bits in @dst. See further the comment and
|
|
|
|
* Example [2] for bitmap_onto() for why and how to use this.
|
|
|
|
*/
|
|
|
|
void bitmap_fold(unsigned long *dst, const unsigned long *orig,
|
2015-02-12 23:02:04 +00:00
|
|
|
unsigned int sz, unsigned int nbits)
|
mempolicy: add bitmap_onto() and bitmap_fold() operations
The following adds two more bitmap operators, bitmap_onto() and bitmap_fold(),
with the usual cpumask and nodemask wrappers.
The bitmap_onto() operator computes one bitmap relative to another. If the
n-th bit in the origin mask is set, then the m-th bit of the destination mask
will be set, where m is the position of the n-th set bit in the relative mask.
The bitmap_fold() operator folds a bitmap into a second that has bit m set iff
the input bitmap has some bit n set, where m == n mod sz, for the specified sz
value.
There are two substantive changes between this patch and its
predecessor bitmap_relative:
1) Renamed bitmap_relative() to be bitmap_onto().
2) Added bitmap_fold().
The essential motivation for bitmap_onto() is to provide a mechanism for
converting a cpuset-relative CPU or Node mask to an absolute mask. Cpuset
relative masks are written as if the current task were in a cpuset whose CPUs
or Nodes were just the consecutive ones numbered 0..N-1, for some N. The
bitmap_onto() operator is provided in anticipation of adding support for the
first such cpuset relative mask, by the mbind() and set_mempolicy() system
calls, using a planned flag of MPOL_F_RELATIVE_NODES. These bitmap operators
(and their nodemask wrappers, in particular) will be used in code that
converts the user specified cpuset relative memory policy to a specific system
node numbered policy, given the current mems_allowed of the tasks cpuset.
Such cpuset relative mempolicies will address two deficiencies
of the existing interface between cpusets and mempolicies:
1) A task cannot at present reliably establish a cpuset
relative mempolicy because there is an essential race
condition, in that the tasks cpuset may be changed in
between the time the task can query its cpuset placement,
and the time the task can issue the applicable mbind or
set_memplicy system call.
2) A task cannot at present establish what cpuset relative
mempolicy it would like to have, if it is in a smaller
cpuset than it might have mempolicy preferences for,
because the existing interface only allows specifying
mempolicies for nodes currently allowed by the cpuset.
Cpuset relative mempolicies are useful for tasks that don't distinguish
particularly between one CPU or Node and another, but only between how many of
each are allowed, and the proper placement of threads and memory pages on the
various CPUs and Nodes available.
The motivation for the added bitmap_fold() can be seen in the following
example.
Let's say an application has specified some mempolicies that presume 16 memory
nodes, including say a mempolicy that specified MPOL_F_RELATIVE_NODES (cpuset
relative) nodes 12-15. Then lets say that application is crammed into a
cpuset that only has 8 memory nodes, 0-7. If one just uses bitmap_onto(),
this mempolicy, mapped to that cpuset, would ignore the requested relative
nodes above 7, leaving it empty of nodes. That's not good; better to fold the
higher nodes down, so that some nodes are included in the resulting mapped
mempolicy. In this case, the mempolicy nodes 12-15 are taken modulo 8 (the
weight of the mems_allowed of the confining cpuset), resulting in a mempolicy
specifying nodes 4-7.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: <kosaki.motohiro@jp.fujitsu.com>
Cc: <ray-lk@madrabbit.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-28 09:12:29 +00:00
|
|
|
{
|
2015-02-12 23:02:04 +00:00
|
|
|
unsigned int oldbit;
|
mempolicy: add bitmap_onto() and bitmap_fold() operations
The following adds two more bitmap operators, bitmap_onto() and bitmap_fold(),
with the usual cpumask and nodemask wrappers.
The bitmap_onto() operator computes one bitmap relative to another. If the
n-th bit in the origin mask is set, then the m-th bit of the destination mask
will be set, where m is the position of the n-th set bit in the relative mask.
The bitmap_fold() operator folds a bitmap into a second that has bit m set iff
the input bitmap has some bit n set, where m == n mod sz, for the specified sz
value.
There are two substantive changes between this patch and its
predecessor bitmap_relative:
1) Renamed bitmap_relative() to be bitmap_onto().
2) Added bitmap_fold().
The essential motivation for bitmap_onto() is to provide a mechanism for
converting a cpuset-relative CPU or Node mask to an absolute mask. Cpuset
relative masks are written as if the current task were in a cpuset whose CPUs
or Nodes were just the consecutive ones numbered 0..N-1, for some N. The
bitmap_onto() operator is provided in anticipation of adding support for the
first such cpuset relative mask, by the mbind() and set_mempolicy() system
calls, using a planned flag of MPOL_F_RELATIVE_NODES. These bitmap operators
(and their nodemask wrappers, in particular) will be used in code that
converts the user specified cpuset relative memory policy to a specific system
node numbered policy, given the current mems_allowed of the tasks cpuset.
Such cpuset relative mempolicies will address two deficiencies
of the existing interface between cpusets and mempolicies:
1) A task cannot at present reliably establish a cpuset
relative mempolicy because there is an essential race
condition, in that the tasks cpuset may be changed in
between the time the task can query its cpuset placement,
and the time the task can issue the applicable mbind or
set_memplicy system call.
2) A task cannot at present establish what cpuset relative
mempolicy it would like to have, if it is in a smaller
cpuset than it might have mempolicy preferences for,
because the existing interface only allows specifying
mempolicies for nodes currently allowed by the cpuset.
Cpuset relative mempolicies are useful for tasks that don't distinguish
particularly between one CPU or Node and another, but only between how many of
each are allowed, and the proper placement of threads and memory pages on the
various CPUs and Nodes available.
The motivation for the added bitmap_fold() can be seen in the following
example.
Let's say an application has specified some mempolicies that presume 16 memory
nodes, including say a mempolicy that specified MPOL_F_RELATIVE_NODES (cpuset
relative) nodes 12-15. Then lets say that application is crammed into a
cpuset that only has 8 memory nodes, 0-7. If one just uses bitmap_onto(),
this mempolicy, mapped to that cpuset, would ignore the requested relative
nodes above 7, leaving it empty of nodes. That's not good; better to fold the
higher nodes down, so that some nodes are included in the resulting mapped
mempolicy. In this case, the mempolicy nodes 12-15 are taken modulo 8 (the
weight of the mems_allowed of the confining cpuset), resulting in a mempolicy
specifying nodes 4-7.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: <kosaki.motohiro@jp.fujitsu.com>
Cc: <ray-lk@madrabbit.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-28 09:12:29 +00:00
|
|
|
|
|
|
|
if (dst == orig) /* following doesn't handle inplace mappings */
|
|
|
|
return;
|
2015-02-12 23:02:04 +00:00
|
|
|
bitmap_zero(dst, nbits);
|
mempolicy: add bitmap_onto() and bitmap_fold() operations
The following adds two more bitmap operators, bitmap_onto() and bitmap_fold(),
with the usual cpumask and nodemask wrappers.
The bitmap_onto() operator computes one bitmap relative to another. If the
n-th bit in the origin mask is set, then the m-th bit of the destination mask
will be set, where m is the position of the n-th set bit in the relative mask.
The bitmap_fold() operator folds a bitmap into a second that has bit m set iff
the input bitmap has some bit n set, where m == n mod sz, for the specified sz
value.
There are two substantive changes between this patch and its
predecessor bitmap_relative:
1) Renamed bitmap_relative() to be bitmap_onto().
2) Added bitmap_fold().
The essential motivation for bitmap_onto() is to provide a mechanism for
converting a cpuset-relative CPU or Node mask to an absolute mask. Cpuset
relative masks are written as if the current task were in a cpuset whose CPUs
or Nodes were just the consecutive ones numbered 0..N-1, for some N. The
bitmap_onto() operator is provided in anticipation of adding support for the
first such cpuset relative mask, by the mbind() and set_mempolicy() system
calls, using a planned flag of MPOL_F_RELATIVE_NODES. These bitmap operators
(and their nodemask wrappers, in particular) will be used in code that
converts the user specified cpuset relative memory policy to a specific system
node numbered policy, given the current mems_allowed of the tasks cpuset.
Such cpuset relative mempolicies will address two deficiencies
of the existing interface between cpusets and mempolicies:
1) A task cannot at present reliably establish a cpuset
relative mempolicy because there is an essential race
condition, in that the tasks cpuset may be changed in
between the time the task can query its cpuset placement,
and the time the task can issue the applicable mbind or
set_memplicy system call.
2) A task cannot at present establish what cpuset relative
mempolicy it would like to have, if it is in a smaller
cpuset than it might have mempolicy preferences for,
because the existing interface only allows specifying
mempolicies for nodes currently allowed by the cpuset.
Cpuset relative mempolicies are useful for tasks that don't distinguish
particularly between one CPU or Node and another, but only between how many of
each are allowed, and the proper placement of threads and memory pages on the
various CPUs and Nodes available.
The motivation for the added bitmap_fold() can be seen in the following
example.
Let's say an application has specified some mempolicies that presume 16 memory
nodes, including say a mempolicy that specified MPOL_F_RELATIVE_NODES (cpuset
relative) nodes 12-15. Then lets say that application is crammed into a
cpuset that only has 8 memory nodes, 0-7. If one just uses bitmap_onto(),
this mempolicy, mapped to that cpuset, would ignore the requested relative
nodes above 7, leaving it empty of nodes. That's not good; better to fold the
higher nodes down, so that some nodes are included in the resulting mapped
mempolicy. In this case, the mempolicy nodes 12-15 are taken modulo 8 (the
weight of the mems_allowed of the confining cpuset), resulting in a mempolicy
specifying nodes 4-7.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: <kosaki.motohiro@jp.fujitsu.com>
Cc: <ray-lk@madrabbit.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-28 09:12:29 +00:00
|
|
|
|
2015-02-12 23:02:04 +00:00
|
|
|
for_each_set_bit(oldbit, orig, nbits)
|
mempolicy: add bitmap_onto() and bitmap_fold() operations
The following adds two more bitmap operators, bitmap_onto() and bitmap_fold(),
with the usual cpumask and nodemask wrappers.
The bitmap_onto() operator computes one bitmap relative to another. If the
n-th bit in the origin mask is set, then the m-th bit of the destination mask
will be set, where m is the position of the n-th set bit in the relative mask.
The bitmap_fold() operator folds a bitmap into a second that has bit m set iff
the input bitmap has some bit n set, where m == n mod sz, for the specified sz
value.
There are two substantive changes between this patch and its
predecessor bitmap_relative:
1) Renamed bitmap_relative() to be bitmap_onto().
2) Added bitmap_fold().
The essential motivation for bitmap_onto() is to provide a mechanism for
converting a cpuset-relative CPU or Node mask to an absolute mask. Cpuset
relative masks are written as if the current task were in a cpuset whose CPUs
or Nodes were just the consecutive ones numbered 0..N-1, for some N. The
bitmap_onto() operator is provided in anticipation of adding support for the
first such cpuset relative mask, by the mbind() and set_mempolicy() system
calls, using a planned flag of MPOL_F_RELATIVE_NODES. These bitmap operators
(and their nodemask wrappers, in particular) will be used in code that
converts the user specified cpuset relative memory policy to a specific system
node numbered policy, given the current mems_allowed of the tasks cpuset.
Such cpuset relative mempolicies will address two deficiencies
of the existing interface between cpusets and mempolicies:
1) A task cannot at present reliably establish a cpuset
relative mempolicy because there is an essential race
condition, in that the tasks cpuset may be changed in
between the time the task can query its cpuset placement,
and the time the task can issue the applicable mbind or
set_memplicy system call.
2) A task cannot at present establish what cpuset relative
mempolicy it would like to have, if it is in a smaller
cpuset than it might have mempolicy preferences for,
because the existing interface only allows specifying
mempolicies for nodes currently allowed by the cpuset.
Cpuset relative mempolicies are useful for tasks that don't distinguish
particularly between one CPU or Node and another, but only between how many of
each are allowed, and the proper placement of threads and memory pages on the
various CPUs and Nodes available.
The motivation for the added bitmap_fold() can be seen in the following
example.
Let's say an application has specified some mempolicies that presume 16 memory
nodes, including say a mempolicy that specified MPOL_F_RELATIVE_NODES (cpuset
relative) nodes 12-15. Then lets say that application is crammed into a
cpuset that only has 8 memory nodes, 0-7. If one just uses bitmap_onto(),
this mempolicy, mapped to that cpuset, would ignore the requested relative
nodes above 7, leaving it empty of nodes. That's not good; better to fold the
higher nodes down, so that some nodes are included in the resulting mapped
mempolicy. In this case, the mempolicy nodes 12-15 are taken modulo 8 (the
weight of the mems_allowed of the confining cpuset), resulting in a mempolicy
specifying nodes 4-7.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: <kosaki.motohiro@jp.fujitsu.com>
Cc: <ray-lk@madrabbit.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-28 09:12:29 +00:00
|
|
|
set_bit(oldbit % sz, dst);
|
|
|
|
}
|
2019-05-14 22:42:43 +00:00
|
|
|
#endif /* CONFIG_NUMA */
|
mempolicy: add bitmap_onto() and bitmap_fold() operations
The following adds two more bitmap operators, bitmap_onto() and bitmap_fold(),
with the usual cpumask and nodemask wrappers.
The bitmap_onto() operator computes one bitmap relative to another. If the
n-th bit in the origin mask is set, then the m-th bit of the destination mask
will be set, where m is the position of the n-th set bit in the relative mask.
The bitmap_fold() operator folds a bitmap into a second that has bit m set iff
the input bitmap has some bit n set, where m == n mod sz, for the specified sz
value.
There are two substantive changes between this patch and its
predecessor bitmap_relative:
1) Renamed bitmap_relative() to be bitmap_onto().
2) Added bitmap_fold().
The essential motivation for bitmap_onto() is to provide a mechanism for
converting a cpuset-relative CPU or Node mask to an absolute mask. Cpuset
relative masks are written as if the current task were in a cpuset whose CPUs
or Nodes were just the consecutive ones numbered 0..N-1, for some N. The
bitmap_onto() operator is provided in anticipation of adding support for the
first such cpuset relative mask, by the mbind() and set_mempolicy() system
calls, using a planned flag of MPOL_F_RELATIVE_NODES. These bitmap operators
(and their nodemask wrappers, in particular) will be used in code that
converts the user specified cpuset relative memory policy to a specific system
node numbered policy, given the current mems_allowed of the tasks cpuset.
Such cpuset relative mempolicies will address two deficiencies
of the existing interface between cpusets and mempolicies:
1) A task cannot at present reliably establish a cpuset
relative mempolicy because there is an essential race
condition, in that the tasks cpuset may be changed in
between the time the task can query its cpuset placement,
and the time the task can issue the applicable mbind or
set_memplicy system call.
2) A task cannot at present establish what cpuset relative
mempolicy it would like to have, if it is in a smaller
cpuset than it might have mempolicy preferences for,
because the existing interface only allows specifying
mempolicies for nodes currently allowed by the cpuset.
Cpuset relative mempolicies are useful for tasks that don't distinguish
particularly between one CPU or Node and another, but only between how many of
each are allowed, and the proper placement of threads and memory pages on the
various CPUs and Nodes available.
The motivation for the added bitmap_fold() can be seen in the following
example.
Let's say an application has specified some mempolicies that presume 16 memory
nodes, including say a mempolicy that specified MPOL_F_RELATIVE_NODES (cpuset
relative) nodes 12-15. Then lets say that application is crammed into a
cpuset that only has 8 memory nodes, 0-7. If one just uses bitmap_onto(),
this mempolicy, mapped to that cpuset, would ignore the requested relative
nodes above 7, leaving it empty of nodes. That's not good; better to fold the
higher nodes down, so that some nodes are included in the resulting mapped
mempolicy. In this case, the mempolicy nodes 12-15 are taken modulo 8 (the
weight of the mems_allowed of the confining cpuset), resulting in a mempolicy
specifying nodes 4-7.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: <kosaki.motohiro@jp.fujitsu.com>
Cc: <ray-lk@madrabbit.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-28 09:12:29 +00:00
|
|
|
|
2018-08-01 22:42:56 +00:00
|
|
|
unsigned long *bitmap_alloc(unsigned int nbits, gfp_t flags)
|
|
|
|
{
|
|
|
|
return kmalloc_array(BITS_TO_LONGS(nbits), sizeof(unsigned long),
|
|
|
|
flags);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(bitmap_alloc);
|
|
|
|
|
|
|
|
unsigned long *bitmap_zalloc(unsigned int nbits, gfp_t flags)
|
|
|
|
{
|
|
|
|
return bitmap_alloc(nbits, flags | __GFP_ZERO);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(bitmap_zalloc);
|
|
|
|
|
2020-12-30 09:41:52 +00:00
|
|
|
unsigned long *bitmap_alloc_node(unsigned int nbits, gfp_t flags, int node)
|
|
|
|
{
|
|
|
|
return kmalloc_array_node(BITS_TO_LONGS(nbits), sizeof(unsigned long),
|
|
|
|
flags, node);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(bitmap_alloc_node);
|
|
|
|
|
|
|
|
unsigned long *bitmap_zalloc_node(unsigned int nbits, gfp_t flags, int node)
|
|
|
|
{
|
|
|
|
return bitmap_alloc_node(nbits, flags | __GFP_ZERO, node);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(bitmap_zalloc_node);
|
|
|
|
|
2018-08-01 22:42:56 +00:00
|
|
|
void bitmap_free(const unsigned long *bitmap)
|
|
|
|
{
|
|
|
|
kfree(bitmap);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(bitmap_free);
|
|
|
|
|
2021-03-15 09:13:56 +00:00
|
|
|
static void devm_bitmap_free(void *data)
|
|
|
|
{
|
|
|
|
unsigned long *bitmap = data;
|
|
|
|
|
|
|
|
bitmap_free(bitmap);
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned long *devm_bitmap_alloc(struct device *dev,
|
|
|
|
unsigned int nbits, gfp_t flags)
|
|
|
|
{
|
|
|
|
unsigned long *bitmap;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
bitmap = bitmap_alloc(nbits, flags);
|
|
|
|
if (!bitmap)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
ret = devm_add_action_or_reset(dev, devm_bitmap_free, bitmap);
|
|
|
|
if (ret)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return bitmap;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(devm_bitmap_alloc);
|
|
|
|
|
|
|
|
unsigned long *devm_bitmap_zalloc(struct device *dev,
|
|
|
|
unsigned int nbits, gfp_t flags)
|
|
|
|
{
|
|
|
|
return devm_bitmap_alloc(dev, nbits, flags | __GFP_ZERO);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(devm_bitmap_zalloc);
|
|
|
|
|
bitmap: new bitmap_copy_safe and bitmap_{from,to}_arr32
This patchset replaces bitmap_{to,from}_u32array with more simple and
standard looking copy-like functions.
bitmap_from_u32array() takes 4 arguments (bitmap_to_u32array is similar):
- unsigned long *bitmap, which is destination;
- unsigned int nbits, the length of destination bitmap, in bits;
- const u32 *buf, the source; and
- unsigned int nwords, the length of source buffer in ints.
In description to the function it is detailed like:
* copy min(nbits, 32*nwords) bits from @buf to @bitmap, remaining
* bits between nword and nbits in @bitmap (if any) are cleared.
Having two size arguments looks unneeded and potentially dangerous.
It is unneeded because normally user of copy-like function should take
care of the size of destination and make it big enough to fit source
data.
And it is dangerous because function may hide possible error if user
doesn't provide big enough bitmap, and data becomes silently dropped.
That's why all copy-like functions have 1 argument for size of copying
data, and I don't see any reason to make bitmap_from_u32array()
different.
One exception that comes in mind is strncpy() which also provides size
of destination in arguments, but it's strongly argued by the possibility
of taking broken strings in source. This is not the case of
bitmap_{from,to}_u32array().
There is no many real users of bitmap_{from,to}_u32array(), and they all
very clearly provide size of destination matched with the size of
source, so additional functionality is not used in fact. Like this:
bitmap_from_u32array(to->link_modes.supported,
__ETHTOOL_LINK_MODE_MASK_NBITS,
link_usettings.link_modes.supported,
__ETHTOOL_LINK_MODE_MASK_NU32);
Where:
#define __ETHTOOL_LINK_MODE_MASK_NU32 \
DIV_ROUND_UP(__ETHTOOL_LINK_MODE_MASK_NBITS, 32)
In this patch, bitmap_copy_safe and bitmap_{from,to}_arr32 are introduced.
'Safe' in bitmap_copy_safe() stands for clearing unused bits in bitmap
beyond last bit till the end of last word. It is useful for hardening
API when bitmap is assumed to be exposed to userspace.
bitmap_{from,to}_arr32 functions are replacements for
bitmap_{from,to}_u32array. They don't take unneeded nwords argument, and
so simpler in implementation and understanding.
This patch suggests optimization for 32-bit systems - aliasing
bitmap_{from,to}_arr32 to bitmap_copy_safe.
Other possible optimization is aliasing 64-bit LE bitmap_{from,to}_arr32 to
more generic function(s). But I didn't end up with the function that would
be helpful by itself, and can be used to alias 64-bit LE
bitmap_{from,to}_arr32, like bitmap_copy_safe() does. So I preferred to
leave things as is.
The following patch switches kernel to new API and introduces test for it.
Discussion is here: https://lkml.org/lkml/2017/11/15/592
[ynorov@caviumnetworks.com: rename bitmap_copy_safe to bitmap_copy_clear_tail]
Link: http://lkml.kernel.org/r/20180201172508.5739-3-ynorov@caviumnetworks.com
Link: http://lkml.kernel.org/r/20171228150019.27953-1-ynorov@caviumnetworks.com
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: David Decotigny <decot@googlers.com>,
Cc: David S. Miller <davem@davemloft.net>,
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-02-06 23:38:02 +00:00
|
|
|
#if BITS_PER_LONG == 64
|
|
|
|
/**
|
|
|
|
* bitmap_from_arr32 - copy the contents of u32 array of bits to bitmap
|
|
|
|
* @bitmap: array of unsigned longs, the destination bitmap
|
|
|
|
* @buf: array of u32 (in host byte order), the source bitmap
|
|
|
|
* @nbits: number of bits in @bitmap
|
|
|
|
*/
|
2018-08-22 04:56:59 +00:00
|
|
|
void bitmap_from_arr32(unsigned long *bitmap, const u32 *buf, unsigned int nbits)
|
bitmap: new bitmap_copy_safe and bitmap_{from,to}_arr32
This patchset replaces bitmap_{to,from}_u32array with more simple and
standard looking copy-like functions.
bitmap_from_u32array() takes 4 arguments (bitmap_to_u32array is similar):
- unsigned long *bitmap, which is destination;
- unsigned int nbits, the length of destination bitmap, in bits;
- const u32 *buf, the source; and
- unsigned int nwords, the length of source buffer in ints.
In description to the function it is detailed like:
* copy min(nbits, 32*nwords) bits from @buf to @bitmap, remaining
* bits between nword and nbits in @bitmap (if any) are cleared.
Having two size arguments looks unneeded and potentially dangerous.
It is unneeded because normally user of copy-like function should take
care of the size of destination and make it big enough to fit source
data.
And it is dangerous because function may hide possible error if user
doesn't provide big enough bitmap, and data becomes silently dropped.
That's why all copy-like functions have 1 argument for size of copying
data, and I don't see any reason to make bitmap_from_u32array()
different.
One exception that comes in mind is strncpy() which also provides size
of destination in arguments, but it's strongly argued by the possibility
of taking broken strings in source. This is not the case of
bitmap_{from,to}_u32array().
There is no many real users of bitmap_{from,to}_u32array(), and they all
very clearly provide size of destination matched with the size of
source, so additional functionality is not used in fact. Like this:
bitmap_from_u32array(to->link_modes.supported,
__ETHTOOL_LINK_MODE_MASK_NBITS,
link_usettings.link_modes.supported,
__ETHTOOL_LINK_MODE_MASK_NU32);
Where:
#define __ETHTOOL_LINK_MODE_MASK_NU32 \
DIV_ROUND_UP(__ETHTOOL_LINK_MODE_MASK_NBITS, 32)
In this patch, bitmap_copy_safe and bitmap_{from,to}_arr32 are introduced.
'Safe' in bitmap_copy_safe() stands for clearing unused bits in bitmap
beyond last bit till the end of last word. It is useful for hardening
API when bitmap is assumed to be exposed to userspace.
bitmap_{from,to}_arr32 functions are replacements for
bitmap_{from,to}_u32array. They don't take unneeded nwords argument, and
so simpler in implementation and understanding.
This patch suggests optimization for 32-bit systems - aliasing
bitmap_{from,to}_arr32 to bitmap_copy_safe.
Other possible optimization is aliasing 64-bit LE bitmap_{from,to}_arr32 to
more generic function(s). But I didn't end up with the function that would
be helpful by itself, and can be used to alias 64-bit LE
bitmap_{from,to}_arr32, like bitmap_copy_safe() does. So I preferred to
leave things as is.
The following patch switches kernel to new API and introduces test for it.
Discussion is here: https://lkml.org/lkml/2017/11/15/592
[ynorov@caviumnetworks.com: rename bitmap_copy_safe to bitmap_copy_clear_tail]
Link: http://lkml.kernel.org/r/20180201172508.5739-3-ynorov@caviumnetworks.com
Link: http://lkml.kernel.org/r/20171228150019.27953-1-ynorov@caviumnetworks.com
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: David Decotigny <decot@googlers.com>,
Cc: David S. Miller <davem@davemloft.net>,
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-02-06 23:38:02 +00:00
|
|
|
{
|
|
|
|
unsigned int i, halfwords;
|
|
|
|
|
|
|
|
halfwords = DIV_ROUND_UP(nbits, 32);
|
|
|
|
for (i = 0; i < halfwords; i++) {
|
|
|
|
bitmap[i/2] = (unsigned long) buf[i];
|
|
|
|
if (++i < halfwords)
|
|
|
|
bitmap[i/2] |= ((unsigned long) buf[i]) << 32;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Clear tail bits in last word beyond nbits. */
|
|
|
|
if (nbits % BITS_PER_LONG)
|
|
|
|
bitmap[(halfwords - 1) / 2] &= BITMAP_LAST_WORD_MASK(nbits);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(bitmap_from_arr32);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* bitmap_to_arr32 - copy the contents of bitmap to a u32 array of bits
|
|
|
|
* @buf: array of u32 (in host byte order), the dest bitmap
|
|
|
|
* @bitmap: array of unsigned longs, the source bitmap
|
|
|
|
* @nbits: number of bits in @bitmap
|
|
|
|
*/
|
|
|
|
void bitmap_to_arr32(u32 *buf, const unsigned long *bitmap, unsigned int nbits)
|
|
|
|
{
|
|
|
|
unsigned int i, halfwords;
|
|
|
|
|
|
|
|
halfwords = DIV_ROUND_UP(nbits, 32);
|
|
|
|
for (i = 0; i < halfwords; i++) {
|
|
|
|
buf[i] = (u32) (bitmap[i/2] & UINT_MAX);
|
|
|
|
if (++i < halfwords)
|
|
|
|
buf[i] = (u32) (bitmap[i/2] >> 32);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Clear tail bits in last element of array beyond nbits. */
|
|
|
|
if (nbits % BITS_PER_LONG)
|
|
|
|
buf[halfwords - 1] &= (u32) (UINT_MAX >> ((-nbits) & 31));
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(bitmap_to_arr32);
|
2022-04-28 20:51:13 +00:00
|
|
|
#endif
|
|
|
|
|
2023-02-27 19:24:36 +00:00
|
|
|
#if BITS_PER_LONG == 32
|
2022-04-28 20:51:13 +00:00
|
|
|
/**
|
|
|
|
* bitmap_from_arr64 - copy the contents of u64 array of bits to bitmap
|
|
|
|
* @bitmap: array of unsigned longs, the destination bitmap
|
|
|
|
* @buf: array of u64 (in host byte order), the source bitmap
|
|
|
|
* @nbits: number of bits in @bitmap
|
|
|
|
*/
|
|
|
|
void bitmap_from_arr64(unsigned long *bitmap, const u64 *buf, unsigned int nbits)
|
|
|
|
{
|
|
|
|
int n;
|
|
|
|
|
|
|
|
for (n = nbits; n > 0; n -= 64) {
|
|
|
|
u64 val = *buf++;
|
|
|
|
|
|
|
|
*bitmap++ = val;
|
|
|
|
if (n > 32)
|
|
|
|
*bitmap++ = val >> 32;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Clear tail bits in the last word beyond nbits.
|
|
|
|
*
|
|
|
|
* Negative index is OK because here we point to the word next
|
|
|
|
* to the last word of the bitmap, except for nbits == 0, which
|
|
|
|
* is tested implicitly.
|
|
|
|
*/
|
|
|
|
if (nbits % BITS_PER_LONG)
|
|
|
|
bitmap[-1] &= BITMAP_LAST_WORD_MASK(nbits);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(bitmap_from_arr64);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* bitmap_to_arr64 - copy the contents of bitmap to a u64 array of bits
|
|
|
|
* @buf: array of u64 (in host byte order), the dest bitmap
|
|
|
|
* @bitmap: array of unsigned longs, the source bitmap
|
|
|
|
* @nbits: number of bits in @bitmap
|
|
|
|
*/
|
|
|
|
void bitmap_to_arr64(u64 *buf, const unsigned long *bitmap, unsigned int nbits)
|
|
|
|
{
|
|
|
|
const unsigned long *end = bitmap + BITS_TO_LONGS(nbits);
|
bitmap: new bitmap_copy_safe and bitmap_{from,to}_arr32
This patchset replaces bitmap_{to,from}_u32array with more simple and
standard looking copy-like functions.
bitmap_from_u32array() takes 4 arguments (bitmap_to_u32array is similar):
- unsigned long *bitmap, which is destination;
- unsigned int nbits, the length of destination bitmap, in bits;
- const u32 *buf, the source; and
- unsigned int nwords, the length of source buffer in ints.
In description to the function it is detailed like:
* copy min(nbits, 32*nwords) bits from @buf to @bitmap, remaining
* bits between nword and nbits in @bitmap (if any) are cleared.
Having two size arguments looks unneeded and potentially dangerous.
It is unneeded because normally user of copy-like function should take
care of the size of destination and make it big enough to fit source
data.
And it is dangerous because function may hide possible error if user
doesn't provide big enough bitmap, and data becomes silently dropped.
That's why all copy-like functions have 1 argument for size of copying
data, and I don't see any reason to make bitmap_from_u32array()
different.
One exception that comes in mind is strncpy() which also provides size
of destination in arguments, but it's strongly argued by the possibility
of taking broken strings in source. This is not the case of
bitmap_{from,to}_u32array().
There is no many real users of bitmap_{from,to}_u32array(), and they all
very clearly provide size of destination matched with the size of
source, so additional functionality is not used in fact. Like this:
bitmap_from_u32array(to->link_modes.supported,
__ETHTOOL_LINK_MODE_MASK_NBITS,
link_usettings.link_modes.supported,
__ETHTOOL_LINK_MODE_MASK_NU32);
Where:
#define __ETHTOOL_LINK_MODE_MASK_NU32 \
DIV_ROUND_UP(__ETHTOOL_LINK_MODE_MASK_NBITS, 32)
In this patch, bitmap_copy_safe and bitmap_{from,to}_arr32 are introduced.
'Safe' in bitmap_copy_safe() stands for clearing unused bits in bitmap
beyond last bit till the end of last word. It is useful for hardening
API when bitmap is assumed to be exposed to userspace.
bitmap_{from,to}_arr32 functions are replacements for
bitmap_{from,to}_u32array. They don't take unneeded nwords argument, and
so simpler in implementation and understanding.
This patch suggests optimization for 32-bit systems - aliasing
bitmap_{from,to}_arr32 to bitmap_copy_safe.
Other possible optimization is aliasing 64-bit LE bitmap_{from,to}_arr32 to
more generic function(s). But I didn't end up with the function that would
be helpful by itself, and can be used to alias 64-bit LE
bitmap_{from,to}_arr32, like bitmap_copy_safe() does. So I preferred to
leave things as is.
The following patch switches kernel to new API and introduces test for it.
Discussion is here: https://lkml.org/lkml/2017/11/15/592
[ynorov@caviumnetworks.com: rename bitmap_copy_safe to bitmap_copy_clear_tail]
Link: http://lkml.kernel.org/r/20180201172508.5739-3-ynorov@caviumnetworks.com
Link: http://lkml.kernel.org/r/20171228150019.27953-1-ynorov@caviumnetworks.com
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: David Decotigny <decot@googlers.com>,
Cc: David S. Miller <davem@davemloft.net>,
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-02-06 23:38:02 +00:00
|
|
|
|
2022-04-28 20:51:13 +00:00
|
|
|
while (bitmap < end) {
|
|
|
|
*buf = *bitmap++;
|
|
|
|
if (bitmap < end)
|
|
|
|
*buf |= (u64)(*bitmap++) << 32;
|
|
|
|
buf++;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Clear tail bits in the last element of array beyond nbits. */
|
|
|
|
if (nbits % 64)
|
2022-07-11 18:09:29 +00:00
|
|
|
buf[-1] &= GENMASK_ULL((nbits - 1) % 64, 0);
|
2022-04-28 20:51:13 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(bitmap_to_arr64);
|
bitmap: new bitmap_copy_safe and bitmap_{from,to}_arr32
This patchset replaces bitmap_{to,from}_u32array with more simple and
standard looking copy-like functions.
bitmap_from_u32array() takes 4 arguments (bitmap_to_u32array is similar):
- unsigned long *bitmap, which is destination;
- unsigned int nbits, the length of destination bitmap, in bits;
- const u32 *buf, the source; and
- unsigned int nwords, the length of source buffer in ints.
In description to the function it is detailed like:
* copy min(nbits, 32*nwords) bits from @buf to @bitmap, remaining
* bits between nword and nbits in @bitmap (if any) are cleared.
Having two size arguments looks unneeded and potentially dangerous.
It is unneeded because normally user of copy-like function should take
care of the size of destination and make it big enough to fit source
data.
And it is dangerous because function may hide possible error if user
doesn't provide big enough bitmap, and data becomes silently dropped.
That's why all copy-like functions have 1 argument for size of copying
data, and I don't see any reason to make bitmap_from_u32array()
different.
One exception that comes in mind is strncpy() which also provides size
of destination in arguments, but it's strongly argued by the possibility
of taking broken strings in source. This is not the case of
bitmap_{from,to}_u32array().
There is no many real users of bitmap_{from,to}_u32array(), and they all
very clearly provide size of destination matched with the size of
source, so additional functionality is not used in fact. Like this:
bitmap_from_u32array(to->link_modes.supported,
__ETHTOOL_LINK_MODE_MASK_NBITS,
link_usettings.link_modes.supported,
__ETHTOOL_LINK_MODE_MASK_NU32);
Where:
#define __ETHTOOL_LINK_MODE_MASK_NU32 \
DIV_ROUND_UP(__ETHTOOL_LINK_MODE_MASK_NBITS, 32)
In this patch, bitmap_copy_safe and bitmap_{from,to}_arr32 are introduced.
'Safe' in bitmap_copy_safe() stands for clearing unused bits in bitmap
beyond last bit till the end of last word. It is useful for hardening
API when bitmap is assumed to be exposed to userspace.
bitmap_{from,to}_arr32 functions are replacements for
bitmap_{from,to}_u32array. They don't take unneeded nwords argument, and
so simpler in implementation and understanding.
This patch suggests optimization for 32-bit systems - aliasing
bitmap_{from,to}_arr32 to bitmap_copy_safe.
Other possible optimization is aliasing 64-bit LE bitmap_{from,to}_arr32 to
more generic function(s). But I didn't end up with the function that would
be helpful by itself, and can be used to alias 64-bit LE
bitmap_{from,to}_arr32, like bitmap_copy_safe() does. So I preferred to
leave things as is.
The following patch switches kernel to new API and introduces test for it.
Discussion is here: https://lkml.org/lkml/2017/11/15/592
[ynorov@caviumnetworks.com: rename bitmap_copy_safe to bitmap_copy_clear_tail]
Link: http://lkml.kernel.org/r/20180201172508.5739-3-ynorov@caviumnetworks.com
Link: http://lkml.kernel.org/r/20171228150019.27953-1-ynorov@caviumnetworks.com
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: David Decotigny <decot@googlers.com>,
Cc: David S. Miller <davem@davemloft.net>,
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-02-06 23:38:02 +00:00
|
|
|
#endif
|