2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* lib/bitmap.c
|
|
|
|
* Helper functions for bitmap.h.
|
|
|
|
*
|
|
|
|
* This source code is licensed under the GNU General Public License,
|
|
|
|
* Version 2. See the file COPYING for more details.
|
|
|
|
*/
|
2011-11-17 02:29:17 +00:00
|
|
|
#include <linux/export.h>
|
|
|
|
#include <linux/thread_info.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
#include <linux/ctype.h>
|
|
|
|
#include <linux/errno.h>
|
|
|
|
#include <linux/bitmap.h>
|
|
|
|
#include <linux/bitops.h>
|
2012-01-20 23:35:53 +00:00
|
|
|
#include <linux/bug.h>
|
2016-02-19 14:23:59 +00:00
|
|
|
#include <linux/kernel.h>
|
2018-10-30 22:05:14 +00:00
|
|
|
#include <linux/mm.h>
|
2018-08-01 22:42:56 +00:00
|
|
|
#include <linux/slab.h>
|
2016-02-19 14:23:59 +00:00
|
|
|
#include <linux/string.h>
|
2016-07-14 20:22:57 +00:00
|
|
|
#include <linux/uaccess.h>
|
2014-09-30 13:48:22 +00:00
|
|
|
|
|
|
|
#include <asm/page.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2017-10-16 23:32:51 +00:00
|
|
|
/**
|
|
|
|
* DOC: bitmap introduction
|
|
|
|
*
|
2005-04-16 22:20:36 +00:00
|
|
|
* bitmaps provide an array of bits, implemented using an an
|
|
|
|
* 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.
|
|
|
|
*/
|
|
|
|
|
|
|
|
int __bitmap_equal(const unsigned long *bitmap1,
|
2014-08-06 23:09:53 +00:00
|
|
|
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])
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (bits % BITS_PER_LONG)
|
|
|
|
if ((bitmap1[k] ^ bitmap2[k]) & BITMAP_LAST_WORD_MASK(bits))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__bitmap_equal);
|
|
|
|
|
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);
|
|
|
|
|
2009-08-21 16:26:15 +00:00
|
|
|
int __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);
|
|
|
|
|
2009-08-21 16:26:15 +00:00
|
|
|
int __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);
|
|
|
|
|
|
|
|
int __bitmap_intersects(const unsigned long *bitmap1,
|
2014-08-06 23:10:01 +00:00
|
|
|
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])
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
if (bits % BITS_PER_LONG)
|
|
|
|
if ((bitmap1[k] & bitmap2[k]) & BITMAP_LAST_WORD_MASK(bits))
|
|
|
|
return 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__bitmap_intersects);
|
|
|
|
|
|
|
|
int __bitmap_subset(const unsigned long *bitmap1,
|
2014-08-06 23:10:03 +00:00
|
|
|
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])
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (bits % BITS_PER_LONG)
|
|
|
|
if ((bitmap1[k] & ~bitmap2[k]) & BITMAP_LAST_WORD_MASK(bits))
|
|
|
|
return 0;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__bitmap_subset);
|
|
|
|
|
2014-08-06 23:10:05 +00:00
|
|
|
int __bitmap_weight(const unsigned long *bitmap, unsigned int bits)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2014-08-06 23:10:05 +00:00
|
|
|
unsigned int k, lim = bits/BITS_PER_LONG;
|
|
|
|
int w = 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
for (k = 0; k < lim; k++)
|
2006-03-26 09:39:56 +00:00
|
|
|
w += hweight_long(bitmap[k]);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
if (bits % BITS_PER_LONG)
|
2006-03-26 09:39:56 +00:00
|
|
|
w += hweight_long(bitmap[k] & BITMAP_LAST_WORD_MASK(bits));
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
return w;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__bitmap_weight);
|
|
|
|
|
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
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
2012-12-06 09:39:54 +00:00
|
|
|
* Bitmap printing & parsing functions: first version by Nadia Yvette Chambers,
|
2005-04-16 22:20:36 +00:00
|
|
|
* second version by Paul Jackson, third by Joe Korty.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define CHUNKSZ 32
|
|
|
|
#define nbits_to_hold_value(val) fls(val)
|
|
|
|
#define BASEDEC 10 /* fancier cpuset lists input in decimal */
|
|
|
|
|
|
|
|
/**
|
2006-10-11 08:21:55 +00:00
|
|
|
* __bitmap_parse - convert an ASCII hex string into a bitmap.
|
|
|
|
* @buf: pointer to buffer containing string.
|
|
|
|
* @buflen: buffer size in bytes. If string is smaller than this
|
2005-04-16 22:20:36 +00:00
|
|
|
* then it must be terminated with a \0.
|
2006-10-11 08:21:55 +00:00
|
|
|
* @is_user: location of buffer, 0 indicates kernel space
|
2005-04-16 22:20:36 +00:00
|
|
|
* @maskp: pointer to bitmap array that will contain result.
|
|
|
|
* @nmaskbits: size of bitmap, in bits.
|
|
|
|
*
|
|
|
|
* Commas group hex digits into chunks. Each chunk defines exactly 32
|
|
|
|
* bits of the resultant bitmask. No chunk may specify a value larger
|
2006-06-25 12:48:57 +00:00
|
|
|
* than 32 bits (%-EOVERFLOW), and if a chunk specifies a smaller value
|
|
|
|
* then leading 0-bits are prepended. %-EINVAL is returned for illegal
|
2005-04-16 22:20:36 +00:00
|
|
|
* characters and for grouping errors such as "1,,5", ",44", "," and "".
|
|
|
|
* Leading and trailing whitespace accepted, but not embedded whitespace.
|
|
|
|
*/
|
2006-10-11 08:21:55 +00:00
|
|
|
int __bitmap_parse(const char *buf, unsigned int buflen,
|
|
|
|
int is_user, unsigned long *maskp,
|
|
|
|
int nmaskbits)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
int c, old_c, totaldigits, ndigits, nchunks, nbits;
|
|
|
|
u32 chunk;
|
2011-11-01 00:12:32 +00:00
|
|
|
const char __user __force *ubuf = (const char __user __force *)buf;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
bitmap_zero(maskp, nmaskbits);
|
|
|
|
|
|
|
|
nchunks = nbits = totaldigits = c = 0;
|
|
|
|
do {
|
2015-09-09 22:37:02 +00:00
|
|
|
chunk = 0;
|
|
|
|
ndigits = totaldigits;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* Get the next chunk of the bitmap */
|
2006-10-11 08:21:55 +00:00
|
|
|
while (buflen) {
|
2005-04-16 22:20:36 +00:00
|
|
|
old_c = c;
|
2006-10-11 08:21:55 +00:00
|
|
|
if (is_user) {
|
|
|
|
if (__get_user(c, ubuf++))
|
|
|
|
return -EFAULT;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
c = *buf++;
|
|
|
|
buflen--;
|
2005-04-16 22:20:36 +00:00
|
|
|
if (isspace(c))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the last character was a space and the current
|
|
|
|
* character isn't '\0', we've got embedded whitespace.
|
|
|
|
* This is a no-no, so throw an error.
|
|
|
|
*/
|
|
|
|
if (totaldigits && c && isspace(old_c))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* A '\0' or a ',' signal the end of the chunk */
|
|
|
|
if (c == '\0' || c == ',')
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (!isxdigit(c))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Make sure there are at least 4 free bits in 'chunk'.
|
|
|
|
* If not, this hexdigit will overflow 'chunk', so
|
|
|
|
* throw an error.
|
|
|
|
*/
|
|
|
|
if (chunk & ~((1UL << (CHUNKSZ - 4)) - 1))
|
|
|
|
return -EOVERFLOW;
|
|
|
|
|
2010-10-26 21:23:03 +00:00
|
|
|
chunk = (chunk << 4) | hex_to_bin(c);
|
2015-09-09 22:37:02 +00:00
|
|
|
totaldigits++;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2015-09-09 22:37:02 +00:00
|
|
|
if (ndigits == totaldigits)
|
2005-04-16 22:20:36 +00:00
|
|
|
return -EINVAL;
|
|
|
|
if (nchunks == 0 && chunk == 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
__bitmap_shift_left(maskp, maskp, CHUNKSZ, nmaskbits);
|
|
|
|
*maskp |= chunk;
|
|
|
|
nchunks++;
|
|
|
|
nbits += (nchunks == 1) ? nbits_to_hold_value(chunk) : CHUNKSZ;
|
|
|
|
if (nbits > nmaskbits)
|
|
|
|
return -EOVERFLOW;
|
2006-10-11 08:21:55 +00:00
|
|
|
} while (buflen && c == ',');
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2006-10-11 08:21:55 +00:00
|
|
|
EXPORT_SYMBOL(__bitmap_parse);
|
|
|
|
|
|
|
|
/**
|
2010-03-05 21:43:17 +00:00
|
|
|
* bitmap_parse_user - convert an ASCII hex string in a user buffer into a bitmap
|
2006-10-11 08:21:55 +00:00
|
|
|
*
|
|
|
|
* @ubuf: pointer to user buffer containing string.
|
|
|
|
* @ulen: buffer size in bytes. If string is smaller than this
|
|
|
|
* then it must be terminated with a \0.
|
|
|
|
* @maskp: pointer to bitmap array that will contain result.
|
|
|
|
* @nmaskbits: size of bitmap, in bits.
|
|
|
|
*
|
|
|
|
* Wrapper for __bitmap_parse(), providing it with user buffer.
|
|
|
|
*
|
|
|
|
* We cannot have this as an inline function in bitmap.h because it needs
|
|
|
|
* linux/uaccess.h to get the access_ok() declaration and this causes
|
|
|
|
* cyclic dependencies.
|
|
|
|
*/
|
|
|
|
int bitmap_parse_user(const char __user *ubuf,
|
|
|
|
unsigned int ulen, unsigned long *maskp,
|
|
|
|
int nmaskbits)
|
|
|
|
{
|
Remove 'type' argument from access_ok() function
Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument
of the user address range verification function since we got rid of the
old racy i386-only code to walk page tables by hand.
It existed because the original 80386 would not honor the write protect
bit when in kernel mode, so you had to do COW by hand before doing any
user access. But we haven't supported that in a long time, and these
days the 'type' argument is a purely historical artifact.
A discussion about extending 'user_access_begin()' to do the range
checking resulted this patch, because there is no way we're going to
move the old VERIFY_xyz interface to that model. And it's best done at
the end of the merge window when I've done most of my merges, so let's
just get this done once and for all.
This patch was mostly done with a sed-script, with manual fix-ups for
the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form.
There were a couple of notable cases:
- csky still had the old "verify_area()" name as an alias.
- the iter_iov code had magical hardcoded knowledge of the actual
values of VERIFY_{READ,WRITE} (not that they mattered, since nothing
really used it)
- microblaze used the type argument for a debug printout
but other than those oddities this should be a total no-op patch.
I tried to fix up all architectures, did fairly extensive grepping for
access_ok() uses, and the changes are trivial, but I may have missed
something. Any missed conversion should be trivially fixable, though.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-01-04 02:57:57 +00:00
|
|
|
if (!access_ok(ubuf, ulen))
|
2006-10-11 08:21:55 +00:00
|
|
|
return -EFAULT;
|
2011-11-01 00:12:32 +00:00
|
|
|
return __bitmap_parse((const char __force *)ubuf,
|
|
|
|
ulen, 1, maskp, nmaskbits);
|
|
|
|
|
2006-10-11 08:21:55 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(bitmap_parse_user);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2014-09-30 13:48:22 +00:00
|
|
|
/**
|
|
|
|
* bitmap_print_to_pagebuf - convert bitmap to list or hex format ASCII string
|
|
|
|
* @list: indicates whether the bitmap must be list
|
|
|
|
* @buf: page aligned buffer into which string is placed
|
|
|
|
* @maskp: pointer to bitmap to convert
|
|
|
|
* @nmaskbits: size of bitmap, in bits
|
|
|
|
*
|
|
|
|
* Output format is a comma-separated list of decimal numbers and
|
|
|
|
* ranges if list is specified or hex digits grouped into comma-separated
|
|
|
|
* sets of 8 digits/set. Returns the number of characters written to buf.
|
2015-06-25 22:02:17 +00:00
|
|
|
*
|
2018-10-30 22:05:14 +00:00
|
|
|
* It is assumed that @buf is a pointer into a PAGE_SIZE, page-aligned
|
|
|
|
* area and that sufficient storage remains at @buf to accommodate the
|
|
|
|
* bitmap_print_to_pagebuf() output. Returns the number of characters
|
|
|
|
* actually printed to @buf, excluding terminating '\0'.
|
2014-09-30 13:48:22 +00:00
|
|
|
*/
|
|
|
|
int bitmap_print_to_pagebuf(bool list, char *buf, const unsigned long *maskp,
|
|
|
|
int nmaskbits)
|
|
|
|
{
|
2018-10-30 22:05:14 +00:00
|
|
|
ptrdiff_t len = PAGE_SIZE - offset_in_page(buf);
|
2014-09-30 13:48:22 +00:00
|
|
|
|
2018-10-30 22:05:18 +00:00
|
|
|
return list ? scnprintf(buf, len, "%*pbl\n", nmaskbits, maskp) :
|
|
|
|
scnprintf(buf, len, "%*pb\n", nmaskbits, maskp);
|
2014-09-30 13:48:22 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(bitmap_print_to_pagebuf);
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
bitmap, irq: add smp_affinity_list interface to /proc/irq
Manually adjusting the smp_affinity for IRQ's becomes unwieldy when the
cpu count is large.
Setting smp affinity to cpus 256 to 263 would be:
echo 000000ff,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > smp_affinity
instead of:
echo 256-263 > smp_affinity_list
Think about what it looks like for cpus around say, 4088 to 4095.
We already have many alternate "list" interfaces:
/sys/devices/system/cpu/cpuX/indexY/shared_cpu_list
/sys/devices/system/cpu/cpuX/topology/thread_siblings_list
/sys/devices/system/cpu/cpuX/topology/core_siblings_list
/sys/devices/system/node/nodeX/cpulist
/sys/devices/pci***/***/local_cpulist
Add a companion interface, smp_affinity_list to use cpu lists instead of
cpu maps. This conforms to other companion interfaces where both a map
and a list interface exists.
This required adding a bitmap_parselist_user() function in a manner
similar to the bitmap_parse_user() function.
[akpm@linux-foundation.org: make __bitmap_parselist() static]
Signed-off-by: Mike Travis <travis@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jack Steiner <steiner@sgi.com>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-25 00:13:12 +00:00
|
|
|
* __bitmap_parselist - convert list format ASCII string to bitmap
|
2011-06-15 22:08:10 +00:00
|
|
|
* @buf: read nul-terminated user string from this buffer
|
bitmap, irq: add smp_affinity_list interface to /proc/irq
Manually adjusting the smp_affinity for IRQ's becomes unwieldy when the
cpu count is large.
Setting smp affinity to cpus 256 to 263 would be:
echo 000000ff,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > smp_affinity
instead of:
echo 256-263 > smp_affinity_list
Think about what it looks like for cpus around say, 4088 to 4095.
We already have many alternate "list" interfaces:
/sys/devices/system/cpu/cpuX/indexY/shared_cpu_list
/sys/devices/system/cpu/cpuX/topology/thread_siblings_list
/sys/devices/system/cpu/cpuX/topology/core_siblings_list
/sys/devices/system/node/nodeX/cpulist
/sys/devices/pci***/***/local_cpulist
Add a companion interface, smp_affinity_list to use cpu lists instead of
cpu maps. This conforms to other companion interfaces where both a map
and a list interface exists.
This required adding a bitmap_parselist_user() function in a manner
similar to the bitmap_parse_user() function.
[akpm@linux-foundation.org: make __bitmap_parselist() static]
Signed-off-by: Mike Travis <travis@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jack Steiner <steiner@sgi.com>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-25 00:13:12 +00:00
|
|
|
* @buflen: buffer size in bytes. If string is smaller than this
|
|
|
|
* then it must be terminated with a \0.
|
|
|
|
* @is_user: location of buffer, 0 indicates kernel space
|
2006-06-25 12:48:57 +00:00
|
|
|
* @maskp: write resulting mask here
|
2005-04-16 22:20:36 +00:00
|
|
|
* @nmaskbits: number of bits in mask to be written
|
|
|
|
*
|
|
|
|
* Input format is a comma-separated list of decimal numbers and
|
|
|
|
* ranges. Consecutively set bits are shown as two hyphen-separated
|
|
|
|
* decimal numbers, the smallest and largest bit numbers set in
|
|
|
|
* the range.
|
2016-10-11 20:51:35 +00:00
|
|
|
* Optionally each range can be postfixed to denote that only parts of it
|
|
|
|
* should be set. The range will divided to groups of specific size.
|
|
|
|
* From each group will be used only defined amount of bits.
|
|
|
|
* Syntax: range:used_size/group_size
|
|
|
|
* Example: 0-1023:2/256 ==> 0,1,256,257,512,513,768,769
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2017-03-30 20:11:35 +00:00
|
|
|
* Returns: 0 on success, -errno on invalid input strings. Error values:
|
|
|
|
*
|
|
|
|
* - ``-EINVAL``: second number in range smaller than first
|
|
|
|
* - ``-EINVAL``: invalid character in string
|
|
|
|
* - ``-ERANGE``: bit number specified too large for mask
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
bitmap, irq: add smp_affinity_list interface to /proc/irq
Manually adjusting the smp_affinity for IRQ's becomes unwieldy when the
cpu count is large.
Setting smp affinity to cpus 256 to 263 would be:
echo 000000ff,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > smp_affinity
instead of:
echo 256-263 > smp_affinity_list
Think about what it looks like for cpus around say, 4088 to 4095.
We already have many alternate "list" interfaces:
/sys/devices/system/cpu/cpuX/indexY/shared_cpu_list
/sys/devices/system/cpu/cpuX/topology/thread_siblings_list
/sys/devices/system/cpu/cpuX/topology/core_siblings_list
/sys/devices/system/node/nodeX/cpulist
/sys/devices/pci***/***/local_cpulist
Add a companion interface, smp_affinity_list to use cpu lists instead of
cpu maps. This conforms to other companion interfaces where both a map
and a list interface exists.
This required adding a bitmap_parselist_user() function in a manner
similar to the bitmap_parse_user() function.
[akpm@linux-foundation.org: make __bitmap_parselist() static]
Signed-off-by: Mike Travis <travis@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jack Steiner <steiner@sgi.com>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-25 00:13:12 +00:00
|
|
|
static int __bitmap_parselist(const char *buf, unsigned int buflen,
|
|
|
|
int is_user, unsigned long *maskp,
|
|
|
|
int nmaskbits)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2016-10-11 20:51:35 +00:00
|
|
|
unsigned int a, b, old_a, old_b;
|
lib/bitmap.c: make bitmap_parselist() thread-safe and much faster
Current implementation of bitmap_parselist() uses a static variable to
save local state while setting bits in the bitmap. It is obviously wrong
if we assume execution in multiprocessor environment. Fortunately, it's
possible to rewrite this portion of code to avoid using the static
variable.
It is also possible to set bits in the mask per-range with bitmap_set(),
not per-bit, as it is implemented now, with set_bit(); which is way
faster.
The important side effect of this change is that setting bits in this
function from now is not per-bit atomic and less memory-ordered. This is
because set_bit() guarantees the order of memory accesses, while
bitmap_set() does not. I think that it is the advantage of the new
approach, because the bitmap_parselist() is intended to initialise bit
arrays, and user should protect the whole bitmap during initialisation if
needed. So protecting individual bits looks expensive and useless. Also,
other range-oriented functions in lib/bitmap.c don't worry much about
atomicity.
With all that, setting 2k bits in map with the pattern like 0-2047:128/256
becomes ~50 times faster after applying the patch in my testing
environment (arm64 hosted on qemu).
The second patch of the series adds the test for bitmap_parselist(). It's
not intended to cover all tricky cases, just to make sure that I didn't
screw up during rework.
Link: http://lkml.kernel.org/r/20170807225438.16161-1-ynorov@caviumnetworks.com
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
Cc: Noam Camus <noamca@mellanox.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-08 23:15:34 +00:00
|
|
|
unsigned int group_size, used_size, off;
|
2015-09-09 22:37:08 +00:00
|
|
|
int c, old_c, totaldigits, ndigits;
|
2011-11-01 00:12:32 +00:00
|
|
|
const char __user __force *ubuf = (const char __user __force *)buf;
|
2016-10-11 20:51:35 +00:00
|
|
|
int at_start, in_range, in_partial_range;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
bitmap, irq: add smp_affinity_list interface to /proc/irq
Manually adjusting the smp_affinity for IRQ's becomes unwieldy when the
cpu count is large.
Setting smp affinity to cpus 256 to 263 would be:
echo 000000ff,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > smp_affinity
instead of:
echo 256-263 > smp_affinity_list
Think about what it looks like for cpus around say, 4088 to 4095.
We already have many alternate "list" interfaces:
/sys/devices/system/cpu/cpuX/indexY/shared_cpu_list
/sys/devices/system/cpu/cpuX/topology/thread_siblings_list
/sys/devices/system/cpu/cpuX/topology/core_siblings_list
/sys/devices/system/node/nodeX/cpulist
/sys/devices/pci***/***/local_cpulist
Add a companion interface, smp_affinity_list to use cpu lists instead of
cpu maps. This conforms to other companion interfaces where both a map
and a list interface exists.
This required adding a bitmap_parselist_user() function in a manner
similar to the bitmap_parse_user() function.
[akpm@linux-foundation.org: make __bitmap_parselist() static]
Signed-off-by: Mike Travis <travis@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jack Steiner <steiner@sgi.com>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-25 00:13:12 +00:00
|
|
|
totaldigits = c = 0;
|
2016-10-11 20:51:35 +00:00
|
|
|
old_a = old_b = 0;
|
|
|
|
group_size = used_size = 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
bitmap_zero(maskp, nmaskbits);
|
|
|
|
do {
|
2015-06-25 22:02:08 +00:00
|
|
|
at_start = 1;
|
bitmap, irq: add smp_affinity_list interface to /proc/irq
Manually adjusting the smp_affinity for IRQ's becomes unwieldy when the
cpu count is large.
Setting smp affinity to cpus 256 to 263 would be:
echo 000000ff,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > smp_affinity
instead of:
echo 256-263 > smp_affinity_list
Think about what it looks like for cpus around say, 4088 to 4095.
We already have many alternate "list" interfaces:
/sys/devices/system/cpu/cpuX/indexY/shared_cpu_list
/sys/devices/system/cpu/cpuX/topology/thread_siblings_list
/sys/devices/system/cpu/cpuX/topology/core_siblings_list
/sys/devices/system/node/nodeX/cpulist
/sys/devices/pci***/***/local_cpulist
Add a companion interface, smp_affinity_list to use cpu lists instead of
cpu maps. This conforms to other companion interfaces where both a map
and a list interface exists.
This required adding a bitmap_parselist_user() function in a manner
similar to the bitmap_parse_user() function.
[akpm@linux-foundation.org: make __bitmap_parselist() static]
Signed-off-by: Mike Travis <travis@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jack Steiner <steiner@sgi.com>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-25 00:13:12 +00:00
|
|
|
in_range = 0;
|
2016-10-11 20:51:35 +00:00
|
|
|
in_partial_range = 0;
|
bitmap, irq: add smp_affinity_list interface to /proc/irq
Manually adjusting the smp_affinity for IRQ's becomes unwieldy when the
cpu count is large.
Setting smp affinity to cpus 256 to 263 would be:
echo 000000ff,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > smp_affinity
instead of:
echo 256-263 > smp_affinity_list
Think about what it looks like for cpus around say, 4088 to 4095.
We already have many alternate "list" interfaces:
/sys/devices/system/cpu/cpuX/indexY/shared_cpu_list
/sys/devices/system/cpu/cpuX/topology/thread_siblings_list
/sys/devices/system/cpu/cpuX/topology/core_siblings_list
/sys/devices/system/node/nodeX/cpulist
/sys/devices/pci***/***/local_cpulist
Add a companion interface, smp_affinity_list to use cpu lists instead of
cpu maps. This conforms to other companion interfaces where both a map
and a list interface exists.
This required adding a bitmap_parselist_user() function in a manner
similar to the bitmap_parse_user() function.
[akpm@linux-foundation.org: make __bitmap_parselist() static]
Signed-off-by: Mike Travis <travis@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jack Steiner <steiner@sgi.com>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-25 00:13:12 +00:00
|
|
|
a = b = 0;
|
2015-09-09 22:37:08 +00:00
|
|
|
ndigits = totaldigits;
|
bitmap, irq: add smp_affinity_list interface to /proc/irq
Manually adjusting the smp_affinity for IRQ's becomes unwieldy when the
cpu count is large.
Setting smp affinity to cpus 256 to 263 would be:
echo 000000ff,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > smp_affinity
instead of:
echo 256-263 > smp_affinity_list
Think about what it looks like for cpus around say, 4088 to 4095.
We already have many alternate "list" interfaces:
/sys/devices/system/cpu/cpuX/indexY/shared_cpu_list
/sys/devices/system/cpu/cpuX/topology/thread_siblings_list
/sys/devices/system/cpu/cpuX/topology/core_siblings_list
/sys/devices/system/node/nodeX/cpulist
/sys/devices/pci***/***/local_cpulist
Add a companion interface, smp_affinity_list to use cpu lists instead of
cpu maps. This conforms to other companion interfaces where both a map
and a list interface exists.
This required adding a bitmap_parselist_user() function in a manner
similar to the bitmap_parse_user() function.
[akpm@linux-foundation.org: make __bitmap_parselist() static]
Signed-off-by: Mike Travis <travis@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jack Steiner <steiner@sgi.com>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-25 00:13:12 +00:00
|
|
|
|
|
|
|
/* Get the next cpu# or a range of cpu#'s */
|
|
|
|
while (buflen) {
|
|
|
|
old_c = c;
|
|
|
|
if (is_user) {
|
|
|
|
if (__get_user(c, ubuf++))
|
|
|
|
return -EFAULT;
|
|
|
|
} else
|
|
|
|
c = *buf++;
|
|
|
|
buflen--;
|
|
|
|
if (isspace(c))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* A '\0' or a ',' signal the end of a cpu# or range */
|
|
|
|
if (c == '\0' || c == ',')
|
|
|
|
break;
|
2015-09-09 22:37:08 +00:00
|
|
|
/*
|
|
|
|
* whitespaces between digits are not allowed,
|
|
|
|
* but it's ok if whitespaces are on head or tail.
|
|
|
|
* when old_c is whilespace,
|
|
|
|
* if totaldigits == ndigits, whitespace is on head.
|
|
|
|
* if whitespace is on tail, it should not run here.
|
|
|
|
* as c was ',' or '\0',
|
|
|
|
* the last code line has broken the current loop.
|
|
|
|
*/
|
|
|
|
if ((totaldigits != ndigits) && isspace(old_c))
|
|
|
|
return -EINVAL;
|
bitmap, irq: add smp_affinity_list interface to /proc/irq
Manually adjusting the smp_affinity for IRQ's becomes unwieldy when the
cpu count is large.
Setting smp affinity to cpus 256 to 263 would be:
echo 000000ff,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > smp_affinity
instead of:
echo 256-263 > smp_affinity_list
Think about what it looks like for cpus around say, 4088 to 4095.
We already have many alternate "list" interfaces:
/sys/devices/system/cpu/cpuX/indexY/shared_cpu_list
/sys/devices/system/cpu/cpuX/topology/thread_siblings_list
/sys/devices/system/cpu/cpuX/topology/core_siblings_list
/sys/devices/system/node/nodeX/cpulist
/sys/devices/pci***/***/local_cpulist
Add a companion interface, smp_affinity_list to use cpu lists instead of
cpu maps. This conforms to other companion interfaces where both a map
and a list interface exists.
This required adding a bitmap_parselist_user() function in a manner
similar to the bitmap_parse_user() function.
[akpm@linux-foundation.org: make __bitmap_parselist() static]
Signed-off-by: Mike Travis <travis@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jack Steiner <steiner@sgi.com>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-25 00:13:12 +00:00
|
|
|
|
2016-10-11 20:51:35 +00:00
|
|
|
if (c == '/') {
|
|
|
|
used_size = a;
|
|
|
|
at_start = 1;
|
|
|
|
in_range = 0;
|
|
|
|
a = b = 0;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (c == ':') {
|
|
|
|
old_a = a;
|
|
|
|
old_b = b;
|
|
|
|
at_start = 1;
|
|
|
|
in_range = 0;
|
|
|
|
in_partial_range = 1;
|
|
|
|
a = b = 0;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
bitmap, irq: add smp_affinity_list interface to /proc/irq
Manually adjusting the smp_affinity for IRQ's becomes unwieldy when the
cpu count is large.
Setting smp affinity to cpus 256 to 263 would be:
echo 000000ff,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > smp_affinity
instead of:
echo 256-263 > smp_affinity_list
Think about what it looks like for cpus around say, 4088 to 4095.
We already have many alternate "list" interfaces:
/sys/devices/system/cpu/cpuX/indexY/shared_cpu_list
/sys/devices/system/cpu/cpuX/topology/thread_siblings_list
/sys/devices/system/cpu/cpuX/topology/core_siblings_list
/sys/devices/system/node/nodeX/cpulist
/sys/devices/pci***/***/local_cpulist
Add a companion interface, smp_affinity_list to use cpu lists instead of
cpu maps. This conforms to other companion interfaces where both a map
and a list interface exists.
This required adding a bitmap_parselist_user() function in a manner
similar to the bitmap_parse_user() function.
[akpm@linux-foundation.org: make __bitmap_parselist() static]
Signed-off-by: Mike Travis <travis@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jack Steiner <steiner@sgi.com>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-25 00:13:12 +00:00
|
|
|
if (c == '-') {
|
2015-06-25 22:02:08 +00:00
|
|
|
if (at_start || in_range)
|
bitmap, irq: add smp_affinity_list interface to /proc/irq
Manually adjusting the smp_affinity for IRQ's becomes unwieldy when the
cpu count is large.
Setting smp affinity to cpus 256 to 263 would be:
echo 000000ff,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > smp_affinity
instead of:
echo 256-263 > smp_affinity_list
Think about what it looks like for cpus around say, 4088 to 4095.
We already have many alternate "list" interfaces:
/sys/devices/system/cpu/cpuX/indexY/shared_cpu_list
/sys/devices/system/cpu/cpuX/topology/thread_siblings_list
/sys/devices/system/cpu/cpuX/topology/core_siblings_list
/sys/devices/system/node/nodeX/cpulist
/sys/devices/pci***/***/local_cpulist
Add a companion interface, smp_affinity_list to use cpu lists instead of
cpu maps. This conforms to other companion interfaces where both a map
and a list interface exists.
This required adding a bitmap_parselist_user() function in a manner
similar to the bitmap_parse_user() function.
[akpm@linux-foundation.org: make __bitmap_parselist() static]
Signed-off-by: Mike Travis <travis@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jack Steiner <steiner@sgi.com>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-25 00:13:12 +00:00
|
|
|
return -EINVAL;
|
|
|
|
b = 0;
|
|
|
|
in_range = 1;
|
2015-09-09 22:37:05 +00:00
|
|
|
at_start = 1;
|
bitmap, irq: add smp_affinity_list interface to /proc/irq
Manually adjusting the smp_affinity for IRQ's becomes unwieldy when the
cpu count is large.
Setting smp affinity to cpus 256 to 263 would be:
echo 000000ff,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > smp_affinity
instead of:
echo 256-263 > smp_affinity_list
Think about what it looks like for cpus around say, 4088 to 4095.
We already have many alternate "list" interfaces:
/sys/devices/system/cpu/cpuX/indexY/shared_cpu_list
/sys/devices/system/cpu/cpuX/topology/thread_siblings_list
/sys/devices/system/cpu/cpuX/topology/core_siblings_list
/sys/devices/system/node/nodeX/cpulist
/sys/devices/pci***/***/local_cpulist
Add a companion interface, smp_affinity_list to use cpu lists instead of
cpu maps. This conforms to other companion interfaces where both a map
and a list interface exists.
This required adding a bitmap_parselist_user() function in a manner
similar to the bitmap_parse_user() function.
[akpm@linux-foundation.org: make __bitmap_parselist() static]
Signed-off-by: Mike Travis <travis@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jack Steiner <steiner@sgi.com>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-25 00:13:12 +00:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!isdigit(c))
|
2005-04-16 22:20:36 +00:00
|
|
|
return -EINVAL;
|
bitmap, irq: add smp_affinity_list interface to /proc/irq
Manually adjusting the smp_affinity for IRQ's becomes unwieldy when the
cpu count is large.
Setting smp affinity to cpus 256 to 263 would be:
echo 000000ff,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > smp_affinity
instead of:
echo 256-263 > smp_affinity_list
Think about what it looks like for cpus around say, 4088 to 4095.
We already have many alternate "list" interfaces:
/sys/devices/system/cpu/cpuX/indexY/shared_cpu_list
/sys/devices/system/cpu/cpuX/topology/thread_siblings_list
/sys/devices/system/cpu/cpuX/topology/core_siblings_list
/sys/devices/system/node/nodeX/cpulist
/sys/devices/pci***/***/local_cpulist
Add a companion interface, smp_affinity_list to use cpu lists instead of
cpu maps. This conforms to other companion interfaces where both a map
and a list interface exists.
This required adding a bitmap_parselist_user() function in a manner
similar to the bitmap_parse_user() function.
[akpm@linux-foundation.org: make __bitmap_parselist() static]
Signed-off-by: Mike Travis <travis@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jack Steiner <steiner@sgi.com>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-25 00:13:12 +00:00
|
|
|
|
|
|
|
b = b * 10 + (c - '0');
|
|
|
|
if (!in_range)
|
|
|
|
a = b;
|
2015-06-25 22:02:08 +00:00
|
|
|
at_start = 0;
|
bitmap, irq: add smp_affinity_list interface to /proc/irq
Manually adjusting the smp_affinity for IRQ's becomes unwieldy when the
cpu count is large.
Setting smp affinity to cpus 256 to 263 would be:
echo 000000ff,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > smp_affinity
instead of:
echo 256-263 > smp_affinity_list
Think about what it looks like for cpus around say, 4088 to 4095.
We already have many alternate "list" interfaces:
/sys/devices/system/cpu/cpuX/indexY/shared_cpu_list
/sys/devices/system/cpu/cpuX/topology/thread_siblings_list
/sys/devices/system/cpu/cpuX/topology/core_siblings_list
/sys/devices/system/node/nodeX/cpulist
/sys/devices/pci***/***/local_cpulist
Add a companion interface, smp_affinity_list to use cpu lists instead of
cpu maps. This conforms to other companion interfaces where both a map
and a list interface exists.
This required adding a bitmap_parselist_user() function in a manner
similar to the bitmap_parse_user() function.
[akpm@linux-foundation.org: make __bitmap_parselist() static]
Signed-off-by: Mike Travis <travis@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jack Steiner <steiner@sgi.com>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-25 00:13:12 +00:00
|
|
|
totaldigits++;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2015-09-09 22:37:08 +00:00
|
|
|
if (ndigits == totaldigits)
|
|
|
|
continue;
|
2016-10-11 20:51:35 +00:00
|
|
|
if (in_partial_range) {
|
|
|
|
group_size = a;
|
|
|
|
a = old_a;
|
|
|
|
b = old_b;
|
|
|
|
old_a = old_b = 0;
|
lib/bitmap.c: make bitmap_parselist() thread-safe and much faster
Current implementation of bitmap_parselist() uses a static variable to
save local state while setting bits in the bitmap. It is obviously wrong
if we assume execution in multiprocessor environment. Fortunately, it's
possible to rewrite this portion of code to avoid using the static
variable.
It is also possible to set bits in the mask per-range with bitmap_set(),
not per-bit, as it is implemented now, with set_bit(); which is way
faster.
The important side effect of this change is that setting bits in this
function from now is not per-bit atomic and less memory-ordered. This is
because set_bit() guarantees the order of memory accesses, while
bitmap_set() does not. I think that it is the advantage of the new
approach, because the bitmap_parselist() is intended to initialise bit
arrays, and user should protect the whole bitmap during initialisation if
needed. So protecting individual bits looks expensive and useless. Also,
other range-oriented functions in lib/bitmap.c don't worry much about
atomicity.
With all that, setting 2k bits in map with the pattern like 0-2047:128/256
becomes ~50 times faster after applying the patch in my testing
environment (arm64 hosted on qemu).
The second patch of the series adds the test for bitmap_parselist(). It's
not intended to cover all tricky cases, just to make sure that I didn't
screw up during rework.
Link: http://lkml.kernel.org/r/20170807225438.16161-1-ynorov@caviumnetworks.com
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
Cc: Noam Camus <noamca@mellanox.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-08 23:15:34 +00:00
|
|
|
} else {
|
|
|
|
used_size = group_size = b - a + 1;
|
2016-10-11 20:51:35 +00:00
|
|
|
}
|
2015-09-09 22:37:05 +00:00
|
|
|
/* if no digit is after '-', it's wrong*/
|
|
|
|
if (at_start && in_range)
|
|
|
|
return -EINVAL;
|
2018-04-05 23:18:25 +00:00
|
|
|
if (!(a <= b) || group_size == 0 || !(used_size <= group_size))
|
2005-04-16 22:20:36 +00:00
|
|
|
return -EINVAL;
|
|
|
|
if (b >= nmaskbits)
|
|
|
|
return -ERANGE;
|
2015-09-09 22:37:08 +00:00
|
|
|
while (a <= b) {
|
lib/bitmap.c: make bitmap_parselist() thread-safe and much faster
Current implementation of bitmap_parselist() uses a static variable to
save local state while setting bits in the bitmap. It is obviously wrong
if we assume execution in multiprocessor environment. Fortunately, it's
possible to rewrite this portion of code to avoid using the static
variable.
It is also possible to set bits in the mask per-range with bitmap_set(),
not per-bit, as it is implemented now, with set_bit(); which is way
faster.
The important side effect of this change is that setting bits in this
function from now is not per-bit atomic and less memory-ordered. This is
because set_bit() guarantees the order of memory accesses, while
bitmap_set() does not. I think that it is the advantage of the new
approach, because the bitmap_parselist() is intended to initialise bit
arrays, and user should protect the whole bitmap during initialisation if
needed. So protecting individual bits looks expensive and useless. Also,
other range-oriented functions in lib/bitmap.c don't worry much about
atomicity.
With all that, setting 2k bits in map with the pattern like 0-2047:128/256
becomes ~50 times faster after applying the patch in my testing
environment (arm64 hosted on qemu).
The second patch of the series adds the test for bitmap_parselist(). It's
not intended to cover all tricky cases, just to make sure that I didn't
screw up during rework.
Link: http://lkml.kernel.org/r/20170807225438.16161-1-ynorov@caviumnetworks.com
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
Cc: Noam Camus <noamca@mellanox.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-08 23:15:34 +00:00
|
|
|
off = min(b - a + 1, used_size);
|
|
|
|
bitmap_set(maskp, a, off);
|
|
|
|
a += group_size;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
bitmap, irq: add smp_affinity_list interface to /proc/irq
Manually adjusting the smp_affinity for IRQ's becomes unwieldy when the
cpu count is large.
Setting smp affinity to cpus 256 to 263 would be:
echo 000000ff,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > smp_affinity
instead of:
echo 256-263 > smp_affinity_list
Think about what it looks like for cpus around say, 4088 to 4095.
We already have many alternate "list" interfaces:
/sys/devices/system/cpu/cpuX/indexY/shared_cpu_list
/sys/devices/system/cpu/cpuX/topology/thread_siblings_list
/sys/devices/system/cpu/cpuX/topology/core_siblings_list
/sys/devices/system/node/nodeX/cpulist
/sys/devices/pci***/***/local_cpulist
Add a companion interface, smp_affinity_list to use cpu lists instead of
cpu maps. This conforms to other companion interfaces where both a map
and a list interface exists.
This required adding a bitmap_parselist_user() function in a manner
similar to the bitmap_parse_user() function.
[akpm@linux-foundation.org: make __bitmap_parselist() static]
Signed-off-by: Mike Travis <travis@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jack Steiner <steiner@sgi.com>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-25 00:13:12 +00:00
|
|
|
} while (buflen && c == ',');
|
2005-04-16 22:20:36 +00:00
|
|
|
return 0;
|
|
|
|
}
|
bitmap, irq: add smp_affinity_list interface to /proc/irq
Manually adjusting the smp_affinity for IRQ's becomes unwieldy when the
cpu count is large.
Setting smp affinity to cpus 256 to 263 would be:
echo 000000ff,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > smp_affinity
instead of:
echo 256-263 > smp_affinity_list
Think about what it looks like for cpus around say, 4088 to 4095.
We already have many alternate "list" interfaces:
/sys/devices/system/cpu/cpuX/indexY/shared_cpu_list
/sys/devices/system/cpu/cpuX/topology/thread_siblings_list
/sys/devices/system/cpu/cpuX/topology/core_siblings_list
/sys/devices/system/node/nodeX/cpulist
/sys/devices/pci***/***/local_cpulist
Add a companion interface, smp_affinity_list to use cpu lists instead of
cpu maps. This conforms to other companion interfaces where both a map
and a list interface exists.
This required adding a bitmap_parselist_user() function in a manner
similar to the bitmap_parse_user() function.
[akpm@linux-foundation.org: make __bitmap_parselist() static]
Signed-off-by: Mike Travis <travis@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jack Steiner <steiner@sgi.com>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-25 00:13:12 +00:00
|
|
|
|
|
|
|
int bitmap_parselist(const char *bp, unsigned long *maskp, int nmaskbits)
|
|
|
|
{
|
2014-08-06 23:10:12 +00:00
|
|
|
char *nl = strchrnul(bp, '\n');
|
|
|
|
int len = nl - bp;
|
bitmap, irq: add smp_affinity_list interface to /proc/irq
Manually adjusting the smp_affinity for IRQ's becomes unwieldy when the
cpu count is large.
Setting smp affinity to cpus 256 to 263 would be:
echo 000000ff,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > smp_affinity
instead of:
echo 256-263 > smp_affinity_list
Think about what it looks like for cpus around say, 4088 to 4095.
We already have many alternate "list" interfaces:
/sys/devices/system/cpu/cpuX/indexY/shared_cpu_list
/sys/devices/system/cpu/cpuX/topology/thread_siblings_list
/sys/devices/system/cpu/cpuX/topology/core_siblings_list
/sys/devices/system/node/nodeX/cpulist
/sys/devices/pci***/***/local_cpulist
Add a companion interface, smp_affinity_list to use cpu lists instead of
cpu maps. This conforms to other companion interfaces where both a map
and a list interface exists.
This required adding a bitmap_parselist_user() function in a manner
similar to the bitmap_parse_user() function.
[akpm@linux-foundation.org: make __bitmap_parselist() static]
Signed-off-by: Mike Travis <travis@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jack Steiner <steiner@sgi.com>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-25 00:13:12 +00:00
|
|
|
|
|
|
|
return __bitmap_parselist(bp, len, 0, maskp, nmaskbits);
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
EXPORT_SYMBOL(bitmap_parselist);
|
|
|
|
|
bitmap, irq: add smp_affinity_list interface to /proc/irq
Manually adjusting the smp_affinity for IRQ's becomes unwieldy when the
cpu count is large.
Setting smp affinity to cpus 256 to 263 would be:
echo 000000ff,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > smp_affinity
instead of:
echo 256-263 > smp_affinity_list
Think about what it looks like for cpus around say, 4088 to 4095.
We already have many alternate "list" interfaces:
/sys/devices/system/cpu/cpuX/indexY/shared_cpu_list
/sys/devices/system/cpu/cpuX/topology/thread_siblings_list
/sys/devices/system/cpu/cpuX/topology/core_siblings_list
/sys/devices/system/node/nodeX/cpulist
/sys/devices/pci***/***/local_cpulist
Add a companion interface, smp_affinity_list to use cpu lists instead of
cpu maps. This conforms to other companion interfaces where both a map
and a list interface exists.
This required adding a bitmap_parselist_user() function in a manner
similar to the bitmap_parse_user() function.
[akpm@linux-foundation.org: make __bitmap_parselist() static]
Signed-off-by: Mike Travis <travis@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jack Steiner <steiner@sgi.com>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-25 00:13:12 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* bitmap_parselist_user()
|
|
|
|
*
|
|
|
|
* @ubuf: pointer to user buffer containing string.
|
|
|
|
* @ulen: buffer size in bytes. If string is smaller than this
|
|
|
|
* then it must be terminated with a \0.
|
|
|
|
* @maskp: pointer to bitmap array that will contain result.
|
|
|
|
* @nmaskbits: size of bitmap, in bits.
|
|
|
|
*
|
|
|
|
* Wrapper for bitmap_parselist(), providing it with user buffer.
|
|
|
|
*
|
|
|
|
* We cannot have this as an inline function in bitmap.h because it needs
|
|
|
|
* linux/uaccess.h to get the access_ok() declaration and this causes
|
|
|
|
* cyclic dependencies.
|
|
|
|
*/
|
|
|
|
int bitmap_parselist_user(const char __user *ubuf,
|
|
|
|
unsigned int ulen, unsigned long *maskp,
|
|
|
|
int nmaskbits)
|
|
|
|
{
|
Remove 'type' argument from access_ok() function
Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument
of the user address range verification function since we got rid of the
old racy i386-only code to walk page tables by hand.
It existed because the original 80386 would not honor the write protect
bit when in kernel mode, so you had to do COW by hand before doing any
user access. But we haven't supported that in a long time, and these
days the 'type' argument is a purely historical artifact.
A discussion about extending 'user_access_begin()' to do the range
checking resulted this patch, because there is no way we're going to
move the old VERIFY_xyz interface to that model. And it's best done at
the end of the merge window when I've done most of my merges, so let's
just get this done once and for all.
This patch was mostly done with a sed-script, with manual fix-ups for
the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form.
There were a couple of notable cases:
- csky still had the old "verify_area()" name as an alias.
- the iter_iov code had magical hardcoded knowledge of the actual
values of VERIFY_{READ,WRITE} (not that they mattered, since nothing
really used it)
- microblaze used the type argument for a debug printout
but other than those oddities this should be a total no-op patch.
I tried to fix up all architectures, did fairly extensive grepping for
access_ok() uses, and the changes are trivial, but I may have missed
something. Any missed conversion should be trivially fixable, though.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-01-04 02:57:57 +00:00
|
|
|
if (!access_ok(ubuf, ulen))
|
bitmap, irq: add smp_affinity_list interface to /proc/irq
Manually adjusting the smp_affinity for IRQ's becomes unwieldy when the
cpu count is large.
Setting smp affinity to cpus 256 to 263 would be:
echo 000000ff,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > smp_affinity
instead of:
echo 256-263 > smp_affinity_list
Think about what it looks like for cpus around say, 4088 to 4095.
We already have many alternate "list" interfaces:
/sys/devices/system/cpu/cpuX/indexY/shared_cpu_list
/sys/devices/system/cpu/cpuX/topology/thread_siblings_list
/sys/devices/system/cpu/cpuX/topology/core_siblings_list
/sys/devices/system/node/nodeX/cpulist
/sys/devices/pci***/***/local_cpulist
Add a companion interface, smp_affinity_list to use cpu lists instead of
cpu maps. This conforms to other companion interfaces where both a map
and a list interface exists.
This required adding a bitmap_parselist_user() function in a manner
similar to the bitmap_parse_user() function.
[akpm@linux-foundation.org: make __bitmap_parselist() static]
Signed-off-by: Mike Travis <travis@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jack Steiner <steiner@sgi.com>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-25 00:13:12 +00:00
|
|
|
return -EFAULT;
|
2011-11-01 00:12:32 +00:00
|
|
|
return __bitmap_parselist((const char __force *)ubuf,
|
bitmap, irq: add smp_affinity_list interface to /proc/irq
Manually adjusting the smp_affinity for IRQ's becomes unwieldy when the
cpu count is large.
Setting smp affinity to cpus 256 to 263 would be:
echo 000000ff,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > smp_affinity
instead of:
echo 256-263 > smp_affinity_list
Think about what it looks like for cpus around say, 4088 to 4095.
We already have many alternate "list" interfaces:
/sys/devices/system/cpu/cpuX/indexY/shared_cpu_list
/sys/devices/system/cpu/cpuX/topology/thread_siblings_list
/sys/devices/system/cpu/cpuX/topology/core_siblings_list
/sys/devices/system/node/nodeX/cpulist
/sys/devices/pci***/***/local_cpulist
Add a companion interface, smp_affinity_list to use cpu lists instead of
cpu maps. This conforms to other companion interfaces where both a map
and a list interface exists.
This required adding a bitmap_parselist_user() function in a manner
similar to the bitmap_parse_user() function.
[akpm@linux-foundation.org: make __bitmap_parselist() static]
Signed-off-by: Mike Travis <travis@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jack Steiner <steiner@sgi.com>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-25 00:13:12 +00:00
|
|
|
ulen, 1, maskp, nmaskbits);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(bitmap_parselist_user);
|
|
|
|
|
|
|
|
|
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
|
|
|
|
2015-02-12 23:02:07 +00:00
|
|
|
return __bitmap_weight(buf, pos);
|
2005-10-30 23:02:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2010-03-05 21:43:17 +00:00
|
|
|
* bitmap_ord_to_pos - find position of n-th set bit in bitmap
|
2005-10-30 23:02:33 +00:00
|
|
|
* @buf: pointer to bitmap
|
|
|
|
* @ord: ordinal bit position (n-th set bit, n >= 0)
|
2015-02-12 23:02:10 +00:00
|
|
|
* @nbits: number of valid bit positions in @buf
|
2005-10-30 23:02:33 +00:00
|
|
|
*
|
|
|
|
* Map the ordinal offset of bit @ord in @buf to its position in @buf.
|
2015-02-12 23:02:10 +00:00
|
|
|
* Value of @ord should be in range 0 <= @ord < weight(buf). If @ord
|
|
|
|
* >= weight(buf), returns @nbits.
|
2005-10-30 23:02:33 +00:00
|
|
|
*
|
|
|
|
* If for example, just bits 4 through 7 are set in @buf, then @ord
|
|
|
|
* values 0 through 3 will get mapped to 4 through 7, respectively,
|
2015-02-12 23:02:10 +00:00
|
|
|
* and all other @ord values returns @nbits. When @ord value 3
|
2005-10-30 23:02:33 +00:00
|
|
|
* gets mapped to (returns) @pos value 7 in this example, that means
|
|
|
|
* that the 3rd set bit (starting with 0th) is at position 7 in @buf.
|
|
|
|
*
|
2015-02-12 23:02:10 +00:00
|
|
|
* The bit positions 0 through @nbits-1 are valid positions in @buf.
|
2005-10-30 23:02:33 +00:00
|
|
|
*/
|
2015-02-12 23:02:10 +00:00
|
|
|
unsigned int bitmap_ord_to_pos(const unsigned long *buf, unsigned int ord, unsigned int nbits)
|
2005-10-30 23:02:33 +00:00
|
|
|
{
|
2015-02-12 23:02:10 +00:00
|
|
|
unsigned int pos;
|
2005-10-30 23:02:33 +00:00
|
|
|
|
2015-02-12 23:02:10 +00:00
|
|
|
for (pos = find_first_bit(buf, nbits);
|
|
|
|
pos < nbits && ord;
|
|
|
|
pos = find_next_bit(buf, nbits, pos + 1))
|
|
|
|
ord--;
|
2005-10-30 23:02:33 +00:00
|
|
|
|
|
|
|
return pos;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* 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
|
|
|
|
* (the identify 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
|
2015-02-12 23:02:13 +00:00
|
|
|
set_bit(bitmap_ord_to_pos(new, n % w, nbits), dst);
|
2005-10-30 23:02:33 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(bitmap_remap);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* 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
|
|
|
|
* (the identify 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
|
|
|
|
return bitmap_ord_to_pos(new, n % w, bits);
|
2005-10-30 23:02:33 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(bitmap_bitremap);
|
|
|
|
|
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++) {
|
|
|
|
* n = bitmap_ord_to_pos(orig, m, bits);
|
|
|
|
* 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++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(bitmap_onto);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* 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);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(bitmap_fold);
|
|
|
|
|
2006-03-24 11:15:46 +00:00
|
|
|
/*
|
|
|
|
* Common code for bitmap_*_region() routines.
|
|
|
|
* bitmap: array of unsigned longs corresponding to the bitmap
|
|
|
|
* pos: the beginning of the region
|
|
|
|
* order: region size (log base 2 of number of bits)
|
|
|
|
* reg_op: operation(s) to perform on that region of bitmap
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2006-03-24 11:15:46 +00:00
|
|
|
* Can set, verify and/or release a region of bits in a bitmap,
|
|
|
|
* depending on which combination of REG_OP_* flag bits is set.
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2006-03-24 11:15:46 +00:00
|
|
|
* A region of a bitmap is a sequence of bits in the bitmap, of
|
|
|
|
* some size '1 << order' (a power of two), aligned to that same
|
|
|
|
* '1 << order' power of two.
|
|
|
|
*
|
|
|
|
* Returns 1 if REG_OP_ISFREE succeeds (region is all zero bits).
|
|
|
|
* Returns 0 in all other cases and reg_ops.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2006-03-24 11:15:46 +00:00
|
|
|
|
|
|
|
enum {
|
|
|
|
REG_OP_ISFREE, /* true if region is all zero bits */
|
|
|
|
REG_OP_ALLOC, /* set all bits in region */
|
|
|
|
REG_OP_RELEASE, /* clear all bits in region */
|
|
|
|
};
|
|
|
|
|
2014-08-06 23:10:16 +00:00
|
|
|
static int __reg_op(unsigned long *bitmap, unsigned int pos, int order, int reg_op)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2006-03-24 11:15:46 +00:00
|
|
|
int nbits_reg; /* number of bits in region */
|
|
|
|
int index; /* index first long of region in bitmap */
|
|
|
|
int offset; /* bit offset region in bitmap[index] */
|
|
|
|
int nlongs_reg; /* num longs spanned by region in bitmap */
|
2006-03-24 11:15:45 +00:00
|
|
|
int nbitsinlong; /* num bits of region in each spanned long */
|
2006-03-24 11:15:46 +00:00
|
|
|
unsigned long mask; /* bitmask for one long of region */
|
2006-03-24 11:15:45 +00:00
|
|
|
int i; /* scans bitmap by longs */
|
2006-03-24 11:15:46 +00:00
|
|
|
int ret = 0; /* return value */
|
2006-03-24 11:15:45 +00:00
|
|
|
|
2006-03-24 11:15:46 +00:00
|
|
|
/*
|
|
|
|
* Either nlongs_reg == 1 (for small orders that fit in one long)
|
|
|
|
* or (offset == 0 && mask == ~0UL) (for larger multiword orders.)
|
|
|
|
*/
|
|
|
|
nbits_reg = 1 << order;
|
|
|
|
index = pos / BITS_PER_LONG;
|
|
|
|
offset = pos - (index * BITS_PER_LONG);
|
|
|
|
nlongs_reg = BITS_TO_LONGS(nbits_reg);
|
|
|
|
nbitsinlong = min(nbits_reg, BITS_PER_LONG);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2006-03-24 11:15:46 +00:00
|
|
|
/*
|
|
|
|
* Can't do "mask = (1UL << nbitsinlong) - 1", as that
|
|
|
|
* overflows if nbitsinlong == BITS_PER_LONG.
|
|
|
|
*/
|
2006-03-24 11:15:45 +00:00
|
|
|
mask = (1UL << (nbitsinlong - 1));
|
2005-04-16 22:20:36 +00:00
|
|
|
mask += mask - 1;
|
2006-03-24 11:15:46 +00:00
|
|
|
mask <<= offset;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2006-03-24 11:15:46 +00:00
|
|
|
switch (reg_op) {
|
|
|
|
case REG_OP_ISFREE:
|
|
|
|
for (i = 0; i < nlongs_reg; i++) {
|
|
|
|
if (bitmap[index + i] & mask)
|
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
ret = 1; /* all bits in region free (zero) */
|
|
|
|
break;
|
|
|
|
|
|
|
|
case REG_OP_ALLOC:
|
|
|
|
for (i = 0; i < nlongs_reg; i++)
|
|
|
|
bitmap[index + i] |= mask;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case REG_OP_RELEASE:
|
|
|
|
for (i = 0; i < nlongs_reg; i++)
|
|
|
|
bitmap[index + i] &= ~mask;
|
|
|
|
break;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2006-03-24 11:15:46 +00:00
|
|
|
done:
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* bitmap_find_free_region - find a contiguous aligned mem region
|
|
|
|
* @bitmap: array of unsigned longs corresponding to the bitmap
|
|
|
|
* @bits: number of bits in the bitmap
|
|
|
|
* @order: region size (log base 2 of number of bits) to find
|
|
|
|
*
|
|
|
|
* Find a region of free (zero) bits in a @bitmap of @bits bits and
|
|
|
|
* allocate them (set them to one). Only consider regions of length
|
|
|
|
* a power (@order) of two, aligned to that power of two, which
|
|
|
|
* makes the search algorithm much faster.
|
|
|
|
*
|
|
|
|
* Return the bit offset in bitmap of the allocated region,
|
|
|
|
* or -errno on failure.
|
|
|
|
*/
|
2014-08-06 23:10:16 +00:00
|
|
|
int bitmap_find_free_region(unsigned long *bitmap, unsigned int bits, int order)
|
2006-03-24 11:15:46 +00:00
|
|
|
{
|
2014-08-06 23:10:16 +00:00
|
|
|
unsigned int pos, end; /* scans bitmap by regions of size order */
|
2009-03-13 02:32:51 +00:00
|
|
|
|
2014-08-06 23:10:16 +00:00
|
|
|
for (pos = 0 ; (end = pos + (1U << order)) <= bits; pos = end) {
|
2009-03-13 02:32:51 +00:00
|
|
|
if (!__reg_op(bitmap, pos, order, REG_OP_ISFREE))
|
|
|
|
continue;
|
|
|
|
__reg_op(bitmap, pos, order, REG_OP_ALLOC);
|
|
|
|
return pos;
|
|
|
|
}
|
|
|
|
return -ENOMEM;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(bitmap_find_free_region);
|
|
|
|
|
|
|
|
/**
|
2006-03-24 11:15:44 +00:00
|
|
|
* bitmap_release_region - release allocated bitmap region
|
2006-03-24 11:15:46 +00:00
|
|
|
* @bitmap: array of unsigned longs corresponding to the bitmap
|
|
|
|
* @pos: beginning of bit region to release
|
|
|
|
* @order: region size (log base 2 of number of bits) to release
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2007-02-10 09:45:59 +00:00
|
|
|
* This is the complement to __bitmap_find_free_region() and releases
|
2005-04-16 22:20:36 +00:00
|
|
|
* the found region (by clearing it in the bitmap).
|
2006-03-24 11:15:46 +00:00
|
|
|
*
|
|
|
|
* No return value.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2014-08-06 23:10:16 +00:00
|
|
|
void bitmap_release_region(unsigned long *bitmap, unsigned int pos, int order)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2006-03-24 11:15:46 +00:00
|
|
|
__reg_op(bitmap, pos, order, REG_OP_RELEASE);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(bitmap_release_region);
|
|
|
|
|
2006-03-24 11:15:44 +00:00
|
|
|
/**
|
|
|
|
* bitmap_allocate_region - allocate bitmap region
|
2006-03-24 11:15:46 +00:00
|
|
|
* @bitmap: array of unsigned longs corresponding to the bitmap
|
|
|
|
* @pos: beginning of bit region to allocate
|
|
|
|
* @order: region size (log base 2 of number of bits) to allocate
|
2006-03-24 11:15:44 +00:00
|
|
|
*
|
|
|
|
* Allocate (set bits in) a specified region of a bitmap.
|
2006-03-24 11:15:46 +00:00
|
|
|
*
|
2006-06-25 12:48:57 +00:00
|
|
|
* Return 0 on success, or %-EBUSY if specified region wasn't
|
2006-03-24 11:15:44 +00:00
|
|
|
* free (not all bits were zero).
|
|
|
|
*/
|
2014-08-06 23:10:16 +00:00
|
|
|
int bitmap_allocate_region(unsigned long *bitmap, unsigned int pos, int order)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2006-03-24 11:15:46 +00:00
|
|
|
if (!__reg_op(bitmap, pos, order, REG_OP_ISFREE))
|
|
|
|
return -EBUSY;
|
2014-08-06 23:10:18 +00:00
|
|
|
return __reg_op(bitmap, pos, order, REG_OP_ALLOC);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(bitmap_allocate_region);
|
2008-09-17 15:34:03 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* bitmap_copy_le - copy a bitmap, putting the bits into little-endian order.
|
|
|
|
* @dst: destination buffer
|
|
|
|
* @src: bitmap to copy
|
|
|
|
* @nbits: number of bits in the bitmap
|
|
|
|
*
|
|
|
|
* Require nbits % BITS_PER_LONG == 0.
|
|
|
|
*/
|
2015-02-13 22:36:00 +00:00
|
|
|
#ifdef __BIG_ENDIAN
|
2015-02-13 22:35:57 +00:00
|
|
|
void bitmap_copy_le(unsigned long *dst, const unsigned long *src, unsigned int nbits)
|
2008-09-17 15:34:03 +00:00
|
|
|
{
|
2015-02-13 22:35:57 +00:00
|
|
|
unsigned int i;
|
2008-09-17 15:34:03 +00:00
|
|
|
|
|
|
|
for (i = 0; i < nbits/BITS_PER_LONG; i++) {
|
|
|
|
if (BITS_PER_LONG == 64)
|
2015-02-13 22:35:57 +00:00
|
|
|
dst[i] = cpu_to_le64(src[i]);
|
2008-09-17 15:34:03 +00:00
|
|
|
else
|
2015-02-13 22:35:57 +00:00
|
|
|
dst[i] = cpu_to_le32(src[i]);
|
2008-09-17 15:34:03 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(bitmap_copy_le);
|
2015-02-13 22:36:00 +00:00
|
|
|
#endif
|
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
|
|
|
|
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);
|
|
|
|
|
|
|
|
void bitmap_free(const unsigned long *bitmap)
|
|
|
|
{
|
|
|
|
kfree(bitmap);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(bitmap_free);
|
|
|
|
|
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);
|
|
|
|
|
|
|
|
#endif
|