2019-06-03 08:44:46 +03:00
// SPDX-License-Identifier: GPL-2.0-only
2005-04-17 02:20:36 +04:00
/*
* lib / bitmap . c
* Helper functions for bitmap . h .
*/
2021-03-15 12:13:55 +03:00
2005-04-17 02:20:36 +04:00
# include <linux/bitmap.h>
# include <linux/bitops.h>
2012-01-21 03:35:53 +04:00
# include <linux/bug.h>
2021-03-15 12:13:55 +03:00
# include <linux/ctype.h>
2021-03-15 12:13:56 +03:00
# include <linux/device.h>
2021-03-15 12:13:55 +03:00
# include <linux/errno.h>
# include <linux/export.h>
2016-02-19 17:23:59 +03:00
# include <linux/kernel.h>
2018-10-31 01:05:14 +03:00
# include <linux/mm.h>
2018-08-02 01:42:56 +03:00
# include <linux/slab.h>
2016-02-19 17:23:59 +03:00
# include <linux/string.h>
2021-03-15 12:13:55 +03:00
# include <linux/thread_info.h>
2016-07-14 23:22:57 +03:00
# include <linux/uaccess.h>
2014-09-30 17:48:22 +04:00
# include <asm/page.h>
2005-04-17 02:20:36 +04:00
2019-05-15 01:43:14 +03:00
# include "kstrtox.h"
2017-10-17 02:32:51 +03:00
/**
* DOC : bitmap introduction
*
2020-10-16 06:10:45 +03:00
* bitmaps provide an array of bits , implemented using an
2005-04-17 02:20:36 +04:00
* array of unsigned longs . The number of valid bits in a
* given bitmap does _not_ need to be an exact multiple of
* BITS_PER_LONG .
*
* The possible unused bits in the last , partially used word
* of a bitmap are ' don ' t care ' . The implementation makes
* no particular effort to keep them zero . It ensures that
* their value will not affect the results of any operation .
* The bitmap operations that return Boolean ( bitmap_empty ,
* for example ) or scalar ( bitmap_weight , for example ) results
* carefully filter out these unused bits from impacting their
* results .
*
* The byte ordering of bitmaps is more natural on little
* endian architectures . See the big - endian headers
* include / asm - ppc64 / bitops . h and include / asm - s390 / bitops . h
* for the best explanations of this ordering .
*/
2022-05-18 23:52:22 +03:00
bool __bitmap_equal ( const unsigned long * bitmap1 ,
const unsigned long * bitmap2 , unsigned int bits )
2005-04-17 02:20:36 +04:00
{
2014-08-07 03:09:53 +04:00
unsigned int k , lim = bits / BITS_PER_LONG ;
2005-04-17 02:20:36 +04:00
for ( k = 0 ; k < lim ; + + k )
if ( bitmap1 [ k ] ! = bitmap2 [ k ] )
2022-05-18 23:52:22 +03:00
return false ;
2005-04-17 02:20:36 +04:00
if ( bits % BITS_PER_LONG )
if ( ( bitmap1 [ k ] ^ bitmap2 [ k ] ) & BITMAP_LAST_WORD_MASK ( bits ) )
2022-05-18 23:52:22 +03:00
return false ;
2005-04-17 02:20:36 +04:00
2022-05-18 23:52:22 +03:00
return true ;
2005-04-17 02:20:36 +04:00
}
EXPORT_SYMBOL ( __bitmap_equal ) ;
2019-07-22 21:47:24 +03:00
bool __bitmap_or_equal ( const unsigned long * bitmap1 ,
const unsigned long * bitmap2 ,
const unsigned long * bitmap3 ,
unsigned int bits )
{
unsigned int k , lim = bits / BITS_PER_LONG ;
unsigned long tmp ;
for ( k = 0 ; k < lim ; + + k ) {
if ( ( bitmap1 [ k ] | bitmap2 [ k ] ) ! = bitmap3 [ k ] )
return false ;
}
if ( ! ( bits % BITS_PER_LONG ) )
return true ;
tmp = ( bitmap1 [ k ] | bitmap2 [ k ] ) ^ bitmap3 [ k ] ;
return ( tmp & BITMAP_LAST_WORD_MASK ( bits ) ) = = 0 ;
}
2014-08-07 03:09:55 +04:00
void __bitmap_complement ( unsigned long * dst , const unsigned long * src , unsigned int bits )
2005-04-17 02:20:36 +04:00
{
2018-06-08 03:10:41 +03:00
unsigned int k , lim = BITS_TO_LONGS ( bits ) ;
2005-04-17 02:20:36 +04:00
for ( k = 0 ; k < lim ; + + k )
dst [ k ] = ~ src [ k ] ;
}
EXPORT_SYMBOL ( __bitmap_complement ) ;
2007-02-10 12:45:59 +03:00
/**
2005-04-17 02:20:36 +04:00
* __bitmap_shift_right - logical right shift of the bits in a bitmap
2007-03-01 07:12:13 +03:00
* @ dst : destination bitmap
* @ src : source bitmap
* @ shift : shift by this many bits
2015-02-14 01:36:02 +03:00
* @ nbits : bitmap size , in bits
2005-04-17 02:20:36 +04: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-14 01:36:02 +03:00
void __bitmap_shift_right ( unsigned long * dst , const unsigned long * src ,
unsigned shift , unsigned nbits )
2005-04-17 02:20:36 +04:00
{
2015-02-14 01:36:10 +03:00
unsigned k , lim = BITS_TO_LONGS ( nbits ) ;
2015-02-14 01:36:02 +03:00
unsigned off = shift / BITS_PER_LONG , rem = shift % BITS_PER_LONG ;
2015-02-14 01:36:10 +03:00
unsigned long mask = BITMAP_LAST_WORD_MASK ( nbits ) ;
2005-04-17 02:20:36 +04: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-14 01:36:10 +03:00
if ( off + k + 1 = = lim - 1 )
2005-04-17 02:20:36 +04:00
upper & = mask ;
2015-02-14 01:36:05 +03:00
upper < < = ( BITS_PER_LONG - rem ) ;
2005-04-17 02:20:36 +04:00
}
lower = src [ off + k ] ;
2015-02-14 01:36:10 +03:00
if ( off + k = = lim - 1 )
2005-04-17 02:20:36 +04:00
lower & = mask ;
2015-02-14 01:36:05 +03:00
lower > > = rem ;
dst [ k ] = lower | upper ;
2005-04-17 02:20:36 +04:00
}
if ( off )
memset ( & dst [ lim - off ] , 0 , off * sizeof ( unsigned long ) ) ;
}
EXPORT_SYMBOL ( __bitmap_shift_right ) ;
2007-02-10 12:45:59 +03:00
/**
2005-04-17 02:20:36 +04:00
* __bitmap_shift_left - logical left shift of the bits in a bitmap
2007-03-01 07:12:13 +03:00
* @ dst : destination bitmap
* @ src : source bitmap
* @ shift : shift by this many bits
2015-02-14 01:36:13 +03:00
* @ nbits : bitmap size , in bits
2005-04-17 02:20:36 +04: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-14 01:36:13 +03:00
void __bitmap_shift_left ( unsigned long * dst , const unsigned long * src ,
unsigned int shift , unsigned int nbits )
2005-04-17 02:20:36 +04:00
{
2015-02-14 01:36:13 +03:00
int k ;
2015-02-14 01:36:19 +03:00
unsigned int lim = BITS_TO_LONGS ( nbits ) ;
2015-02-14 01:36:13 +03:00
unsigned int off = shift / BITS_PER_LONG , rem = shift % BITS_PER_LONG ;
2005-04-17 02:20:36 +04: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-14 01:36:16 +03:00
lower = src [ k - 1 ] > > ( BITS_PER_LONG - rem ) ;
2005-04-17 02:20:36 +04:00
else
lower = 0 ;
2015-02-14 01:36:19 +03:00
upper = src [ k ] < < rem ;
2015-02-14 01:36:16 +03:00
dst [ k + off ] = lower | upper ;
2005-04-17 02:20:36 +04:00
}
if ( off )
memset ( dst , 0 , off * sizeof ( unsigned long ) ) ;
}
EXPORT_SYMBOL ( __bitmap_shift_left ) ;
2020-01-22 02:17:54 +03:00
/**
* bitmap_cut ( ) - remove bit region from bitmap and right shift remaining bits
* @ dst : destination bitmap , might overlap with src
* @ src : source bitmap
* @ first : start bit of region to be removed
* @ cut : number of bits to remove
* @ nbits : bitmap size , in bits
*
* Set the n - th bit of @ dst iff the n - th bit of @ src is set and
* n is less than @ first , or the m - th bit of @ src is set for any
* m such that @ first < = n < nbits , and m = n + @ cut .
*
* In pictures , example for a big - endian 32 - bit architecture :
*
2020-04-14 19:48:59 +03:00
* The @ src bitmap is : :
2020-01-22 02:17:54 +03:00
*
2020-04-14 19:48:59 +03:00
* 31 63
* | |
* 10000000 11000001 11110010 00010101 10000000 11000001 01110010 00010101
* | | | |
* 16 14 0 32
2020-01-22 02:17:54 +03:00
*
2020-04-14 19:48:59 +03:00
* if @ cut is 3 , and @ first is 14 , bits 14 - 16 in @ src are cut and @ dst is : :
*
* 31 63
* | |
* 10110000 00011000 00110010 00010101 00010000 00011000 00101110 01000010
* | | |
* 14 ( bit 17 0 32
* from @ src )
2020-01-22 02:17:54 +03:00
*
* Note that @ dst and @ src might overlap partially or entirely .
*
* This is implemented in the obvious way , with a shift and carry
* step for each moved bit . Optimisation is left as an exercise
* for the compiler .
*/
void bitmap_cut ( unsigned long * dst , const unsigned long * src ,
unsigned int first , unsigned int cut , unsigned int nbits )
{
unsigned int len = BITS_TO_LONGS ( nbits ) ;
unsigned long keep = 0 , carry ;
int i ;
if ( first % BITS_PER_LONG ) {
keep = src [ first / BITS_PER_LONG ] &
( ~ 0UL > > ( BITS_PER_LONG - first % BITS_PER_LONG ) ) ;
}
2020-08-12 04:34:29 +03:00
memmove ( dst , src , len * sizeof ( * dst ) ) ;
2020-01-22 02:17:54 +03:00
while ( cut - - ) {
for ( i = first / BITS_PER_LONG ; i < len ; i + + ) {
if ( i < len - 1 )
carry = dst [ i + 1 ] & 1UL ;
else
carry = 0 ;
dst [ i ] = ( dst [ i ] > > 1 ) | ( carry < < ( BITS_PER_LONG - 1 ) ) ;
}
}
dst [ first / BITS_PER_LONG ] & = ~ 0UL < < ( first % BITS_PER_LONG ) ;
dst [ first / BITS_PER_LONG ] | = keep ;
}
EXPORT_SYMBOL ( bitmap_cut ) ;
2022-07-01 15:54:24 +03:00
bool __bitmap_and ( unsigned long * dst , const unsigned long * bitmap1 ,
2014-08-07 03:09:59 +04:00
const unsigned long * bitmap2 , unsigned int bits )
2005-04-17 02:20:36 +04:00
{
2014-08-07 03:09:59 +04:00
unsigned int k ;
2014-08-07 03:10:22 +04:00
unsigned int lim = bits / BITS_PER_LONG ;
2009-08-21 20:26:15 +04:00
unsigned long result = 0 ;
2005-04-17 02:20:36 +04:00
2014-08-07 03:10:22 +04:00
for ( k = 0 ; k < lim ; k + + )
2009-08-21 20:26:15 +04:00
result | = ( dst [ k ] = bitmap1 [ k ] & bitmap2 [ k ] ) ;
2014-08-07 03:10:22 +04:00
if ( bits % BITS_PER_LONG )
result | = ( dst [ k ] = bitmap1 [ k ] & bitmap2 [ k ] &
BITMAP_LAST_WORD_MASK ( bits ) ) ;
2009-08-21 20:26:15 +04:00
return result ! = 0 ;
2005-04-17 02:20:36 +04:00
}
EXPORT_SYMBOL ( __bitmap_and ) ;
void __bitmap_or ( unsigned long * dst , const unsigned long * bitmap1 ,
2014-08-07 03:09:59 +04:00
const unsigned long * bitmap2 , unsigned int bits )
2005-04-17 02:20:36 +04:00
{
2014-08-07 03:09:59 +04:00
unsigned int k ;
unsigned int nr = BITS_TO_LONGS ( bits ) ;
2005-04-17 02:20:36 +04: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-07 03:09:59 +04:00
const unsigned long * bitmap2 , unsigned int bits )
2005-04-17 02:20:36 +04:00
{
2014-08-07 03:09:59 +04:00
unsigned int k ;
unsigned int nr = BITS_TO_LONGS ( bits ) ;
2005-04-17 02:20:36 +04:00
for ( k = 0 ; k < nr ; k + + )
dst [ k ] = bitmap1 [ k ] ^ bitmap2 [ k ] ;
}
EXPORT_SYMBOL ( __bitmap_xor ) ;
2022-07-01 15:54:24 +03:00
bool __bitmap_andnot ( unsigned long * dst , const unsigned long * bitmap1 ,
2014-08-07 03:09:59 +04:00
const unsigned long * bitmap2 , unsigned int bits )
2005-04-17 02:20:36 +04:00
{
2014-08-07 03:09:59 +04:00
unsigned int k ;
2014-08-07 03:10:24 +04:00
unsigned int lim = bits / BITS_PER_LONG ;
2009-08-21 20:26:15 +04:00
unsigned long result = 0 ;
2005-04-17 02:20:36 +04:00
2014-08-07 03:10:24 +04:00
for ( k = 0 ; k < lim ; k + + )
2009-08-21 20:26:15 +04:00
result | = ( dst [ k ] = bitmap1 [ k ] & ~ bitmap2 [ k ] ) ;
2014-08-07 03:10:24 +04:00
if ( bits % BITS_PER_LONG )
result | = ( dst [ k ] = bitmap1 [ k ] & ~ bitmap2 [ k ] &
BITMAP_LAST_WORD_MASK ( bits ) ) ;
2009-08-21 20:26:15 +04:00
return result ! = 0 ;
2005-04-17 02:20:36 +04:00
}
EXPORT_SYMBOL ( __bitmap_andnot ) ;
2019-12-05 03:53:26 +03:00
void __bitmap_replace ( unsigned long * dst ,
const unsigned long * old , const unsigned long * new ,
const unsigned long * mask , unsigned int nbits )
{
unsigned int k ;
unsigned int nr = BITS_TO_LONGS ( nbits ) ;
for ( k = 0 ; k < nr ; k + + )
dst [ k ] = ( old [ k ] & ~ mask [ k ] ) | ( new [ k ] & mask [ k ] ) ;
}
EXPORT_SYMBOL ( __bitmap_replace ) ;
2022-05-18 23:52:22 +03:00
bool __bitmap_intersects ( const unsigned long * bitmap1 ,
const unsigned long * bitmap2 , unsigned int bits )
2005-04-17 02:20:36 +04:00
{
2014-08-07 03:10:01 +04:00
unsigned int k , lim = bits / BITS_PER_LONG ;
2005-04-17 02:20:36 +04:00
for ( k = 0 ; k < lim ; + + k )
if ( bitmap1 [ k ] & bitmap2 [ k ] )
2022-05-18 23:52:22 +03:00
return true ;
2005-04-17 02:20:36 +04:00
if ( bits % BITS_PER_LONG )
if ( ( bitmap1 [ k ] & bitmap2 [ k ] ) & BITMAP_LAST_WORD_MASK ( bits ) )
2022-05-18 23:52:22 +03:00
return true ;
return false ;
2005-04-17 02:20:36 +04:00
}
EXPORT_SYMBOL ( __bitmap_intersects ) ;
2022-05-18 23:52:22 +03:00
bool __bitmap_subset ( const unsigned long * bitmap1 ,
const unsigned long * bitmap2 , unsigned int bits )
2005-04-17 02:20:36 +04:00
{
2014-08-07 03:10:03 +04:00
unsigned int k , lim = bits / BITS_PER_LONG ;
2005-04-17 02:20:36 +04:00
for ( k = 0 ; k < lim ; + + k )
if ( bitmap1 [ k ] & ~ bitmap2 [ k ] )
2022-05-18 23:52:22 +03:00
return false ;
2005-04-17 02:20:36 +04:00
if ( bits % BITS_PER_LONG )
if ( ( bitmap1 [ k ] & ~ bitmap2 [ k ] ) & BITMAP_LAST_WORD_MASK ( bits ) )
2022-05-18 23:52:22 +03:00
return false ;
return true ;
2005-04-17 02:20:36 +04:00
}
EXPORT_SYMBOL ( __bitmap_subset ) ;
2022-08-08 03:52:35 +03:00
unsigned int __bitmap_weight ( const unsigned long * bitmap , unsigned int bits )
2005-04-17 02:20:36 +04:00
{
2022-08-08 03:52:35 +03:00
unsigned int k , lim = bits / BITS_PER_LONG , w = 0 ;
2005-04-17 02:20:36 +04:00
for ( k = 0 ; k < lim ; k + + )
2006-03-26 13:39:56 +04:00
w + = hweight_long ( bitmap [ k ] ) ;
2005-04-17 02:20:36 +04:00
if ( bits % BITS_PER_LONG )
2006-03-26 13:39:56 +04:00
w + = hweight_long ( bitmap [ k ] & BITMAP_LAST_WORD_MASK ( bits ) ) ;
2005-04-17 02:20:36 +04:00
return w ;
}
EXPORT_SYMBOL ( __bitmap_weight ) ;
2017-07-11 01:51:29 +03:00
void __bitmap_set ( unsigned long * map , unsigned int start , int len )
2009-12-16 03:48:25 +03:00
{
unsigned long * p = map + BIT_WORD ( start ) ;
2014-08-07 03:10:07 +04:00
const unsigned int size = start + len ;
2009-12-16 03:48:25 +03:00
int bits_to_set = BITS_PER_LONG - ( start % BITS_PER_LONG ) ;
unsigned long mask_to_set = BITMAP_FIRST_WORD_MASK ( start ) ;
2014-08-07 03:10:07 +04:00
while ( len - bits_to_set > = 0 ) {
2009-12-16 03:48:25 +03:00
* p | = mask_to_set ;
2014-08-07 03:10:07 +04:00
len - = bits_to_set ;
2009-12-16 03:48:25 +03:00
bits_to_set = BITS_PER_LONG ;
mask_to_set = ~ 0UL ;
p + + ;
}
2014-08-07 03:10:07 +04:00
if ( len ) {
2009-12-16 03:48:25 +03:00
mask_to_set & = BITMAP_LAST_WORD_MASK ( size ) ;
* p | = mask_to_set ;
}
}
2017-07-11 01:51:29 +03:00
EXPORT_SYMBOL ( __bitmap_set ) ;
2009-12-16 03:48:25 +03:00
2017-07-11 01:51:29 +03:00
void __bitmap_clear ( unsigned long * map , unsigned int start , int len )
2009-12-16 03:48:25 +03:00
{
unsigned long * p = map + BIT_WORD ( start ) ;
2014-08-07 03:10:10 +04:00
const unsigned int size = start + len ;
2009-12-16 03:48:25 +03:00
int bits_to_clear = BITS_PER_LONG - ( start % BITS_PER_LONG ) ;
unsigned long mask_to_clear = BITMAP_FIRST_WORD_MASK ( start ) ;
2014-08-07 03:10:10 +04:00
while ( len - bits_to_clear > = 0 ) {
2009-12-16 03:48:25 +03:00
* p & = ~ mask_to_clear ;
2014-08-07 03:10:10 +04:00
len - = bits_to_clear ;
2009-12-16 03:48:25 +03:00
bits_to_clear = BITS_PER_LONG ;
mask_to_clear = ~ 0UL ;
p + + ;
}
2014-08-07 03:10:10 +04:00
if ( len ) {
2009-12-16 03:48:25 +03:00
mask_to_clear & = BITMAP_LAST_WORD_MASK ( size ) ;
* p & = ~ mask_to_clear ;
}
}
2017-07-11 01:51:29 +03:00
EXPORT_SYMBOL ( __bitmap_clear ) ;
2009-12-16 03:48:25 +03:00
2014-12-13 03:54:45 +03:00
/**
* bitmap_find_next_zero_area_off - find a contiguous aligned zero area
2009-12-16 03:48:25 +03: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 03:54:45 +03:00
* @ align_offset : Alignment offset for zero area .
2009-12-16 03:48:25 +03:00
*
* The @ align_mask should be one less than a power of 2 ; the effect is that
2014-12-13 03:54:45 +03:00
* the bit offset of all zero areas this function finds plus @ align_offset
* is multiple of that power of 2.
2009-12-16 03:48:25 +03:00
*/
2014-12-13 03:54:45 +03: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 03:48:25 +03:00
{
unsigned long index , end , i ;
again :
index = find_next_zero_bit ( map , size , start ) ;
/* Align allocation */
2014-12-13 03:54:45 +03:00
index = __ALIGN_MASK ( index + align_offset , align_mask ) - align_offset ;
2009-12-16 03:48:25 +03: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 03:54:45 +03:00
EXPORT_SYMBOL ( bitmap_find_next_zero_area_off ) ;
2009-12-16 03:48:25 +03:00
2005-04-17 02:20:36 +04:00
/*
2012-12-06 13:39:54 +04:00
* Bitmap printing & parsing functions : first version by Nadia Yvette Chambers ,
2005-04-17 02:20:36 +04:00
* second version by Paul Jackson , third by Joe Korty .
*/
2006-10-11 12:21:55 +04:00
/**
2010-03-06 00:43:17 +03:00
* bitmap_parse_user - convert an ASCII hex string in a user buffer into a bitmap
2006-10-11 12:21:55 +04: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 .
*/
int bitmap_parse_user ( const char __user * ubuf ,
unsigned int ulen , unsigned long * maskp ,
int nmaskbits )
{
2020-02-04 04:37:31 +03:00
char * buf ;
int ret ;
buf = memdup_user_nul ( ubuf , ulen ) ;
if ( IS_ERR ( buf ) )
return PTR_ERR ( buf ) ;
2020-02-04 04:37:34 +03:00
ret = bitmap_parse ( buf , UINT_MAX , maskp , nmaskbits ) ;
2011-11-01 04:12:32 +04:00
2020-02-04 04:37:31 +03:00
kfree ( buf ) ;
return ret ;
2006-10-11 12:21:55 +04:00
}
EXPORT_SYMBOL ( bitmap_parse_user ) ;
2005-04-17 02:20:36 +04:00
2014-09-30 17:48:22 +04: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-26 01:02:17 +03:00
*
2018-10-31 01:05:14 +03: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 17:48:22 +04:00
*/
int bitmap_print_to_pagebuf ( bool list , char * buf , const unsigned long * maskp ,
int nmaskbits )
{
2018-10-31 01:05:14 +03:00
ptrdiff_t len = PAGE_SIZE - offset_in_page ( buf ) ;
2014-09-30 17:48:22 +04:00
2018-10-31 01:05:18 +03:00
return list ? scnprintf ( buf , len , " %*pbl \n " , nmaskbits , maskp ) :
scnprintf ( buf , len , " %*pb \n " , nmaskbits , maskp ) ;
2014-09-30 17:48:22 +04:00
}
EXPORT_SYMBOL ( bitmap_print_to_pagebuf ) ;
cpumask: introduce cpumap_print_list/bitmask_to_buf to support large bitmask and list
The existing cpumap_print_to_pagebuf() is used by cpu topology and other
drivers to export hexadecimal bitmask and decimal list to userspace by
sysfs ABI.
Right now, those drivers are using a normal attribute for this kind of
ABIs. A normal attribute typically has show entry as below:
static ssize_t example_dev_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
...
return cpumap_print_to_pagebuf(true, buf, &pmu_mmdc->cpu);
}
show entry of attribute has no offset and count parameters and this
means the file is limited to one page only.
cpumap_print_to_pagebuf() API works terribly well for this kind of
normal attribute with buf parameter and without offset, count:
static inline ssize_t
cpumap_print_to_pagebuf(bool list, char *buf, const struct cpumask *mask)
{
return bitmap_print_to_pagebuf(list, buf, cpumask_bits(mask),
nr_cpu_ids);
}
The problem is once we have many cpus, we have a chance to make bitmask
or list more than one page. Especially for list, it could be as complex
as 0,3,5,7,9,...... We have no simple way to know it exact size.
It turns out bin_attribute is a way to break this limit. bin_attribute
has show entry as below:
static ssize_t
example_bin_attribute_show(struct file *filp, struct kobject *kobj,
struct bin_attribute *attr, char *buf,
loff_t offset, size_t count)
{
...
}
With the new offset and count parameters, this makes sysfs ABI be able
to support file size more than one page. For example, offset could be
>= 4096.
This patch introduces cpumap_print_bitmask/list_to_buf() and their bitmap
infrastructure bitmap_print_bitmask/list_to_buf() so that those drivers
can move to bin_attribute to support large bitmask and list. At the same
time, we have to pass those corresponding parameters such as offset, count
from bin_attribute to this new API.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Stefano Brivio <sbrivio@redhat.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: "Ma, Jianpeng" <jianpeng.ma@intel.com>
Cc: Yury Norov <yury.norov@gmail.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
Link: https://lore.kernel.org/r/20210806110251.560-2-song.bao.hua@hisilicon.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-06 14:02:47 +03:00
/**
* bitmap_print_to_buf - convert bitmap to list or hex format ASCII string
* @ list : indicates whether the bitmap must be list
* true : print in decimal list format
* false : print in hexadecimal bitmask format
2022-03-24 02:05:53 +03:00
* @ buf : buffer into which string is placed
* @ maskp : pointer to bitmap to convert
* @ nmaskbits : size of bitmap , in bits
* @ off : in the string from which we are copying , We copy to @ buf
* @ count : the maximum number of bytes to print
cpumask: introduce cpumap_print_list/bitmask_to_buf to support large bitmask and list
The existing cpumap_print_to_pagebuf() is used by cpu topology and other
drivers to export hexadecimal bitmask and decimal list to userspace by
sysfs ABI.
Right now, those drivers are using a normal attribute for this kind of
ABIs. A normal attribute typically has show entry as below:
static ssize_t example_dev_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
...
return cpumap_print_to_pagebuf(true, buf, &pmu_mmdc->cpu);
}
show entry of attribute has no offset and count parameters and this
means the file is limited to one page only.
cpumap_print_to_pagebuf() API works terribly well for this kind of
normal attribute with buf parameter and without offset, count:
static inline ssize_t
cpumap_print_to_pagebuf(bool list, char *buf, const struct cpumask *mask)
{
return bitmap_print_to_pagebuf(list, buf, cpumask_bits(mask),
nr_cpu_ids);
}
The problem is once we have many cpus, we have a chance to make bitmask
or list more than one page. Especially for list, it could be as complex
as 0,3,5,7,9,...... We have no simple way to know it exact size.
It turns out bin_attribute is a way to break this limit. bin_attribute
has show entry as below:
static ssize_t
example_bin_attribute_show(struct file *filp, struct kobject *kobj,
struct bin_attribute *attr, char *buf,
loff_t offset, size_t count)
{
...
}
With the new offset and count parameters, this makes sysfs ABI be able
to support file size more than one page. For example, offset could be
>= 4096.
This patch introduces cpumap_print_bitmask/list_to_buf() and their bitmap
infrastructure bitmap_print_bitmask/list_to_buf() so that those drivers
can move to bin_attribute to support large bitmask and list. At the same
time, we have to pass those corresponding parameters such as offset, count
from bin_attribute to this new API.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Stefano Brivio <sbrivio@redhat.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: "Ma, Jianpeng" <jianpeng.ma@intel.com>
Cc: Yury Norov <yury.norov@gmail.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
Link: https://lore.kernel.org/r/20210806110251.560-2-song.bao.hua@hisilicon.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-06 14:02:47 +03:00
*/
static int bitmap_print_to_buf ( bool list , char * buf , const unsigned long * maskp ,
int nmaskbits , loff_t off , size_t count )
{
const char * fmt = list ? " %*pbl \n " : " %*pb \n " ;
ssize_t size ;
void * data ;
data = kasprintf ( GFP_KERNEL , fmt , nmaskbits , maskp ) ;
if ( ! data )
return - ENOMEM ;
size = memory_read_from_buffer ( buf , count , & off , data , strlen ( data ) + 1 ) ;
kfree ( data ) ;
return size ;
}
/**
* bitmap_print_bitmask_to_buf - convert bitmap to hex bitmask format ASCII string
2022-03-24 02:05:53 +03:00
* @ buf : buffer into which string is placed
* @ maskp : pointer to bitmap to convert
* @ nmaskbits : size of bitmap , in bits
* @ off : in the string from which we are copying , We copy to @ buf
* @ count : the maximum number of bytes to print
cpumask: introduce cpumap_print_list/bitmask_to_buf to support large bitmask and list
The existing cpumap_print_to_pagebuf() is used by cpu topology and other
drivers to export hexadecimal bitmask and decimal list to userspace by
sysfs ABI.
Right now, those drivers are using a normal attribute for this kind of
ABIs. A normal attribute typically has show entry as below:
static ssize_t example_dev_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
...
return cpumap_print_to_pagebuf(true, buf, &pmu_mmdc->cpu);
}
show entry of attribute has no offset and count parameters and this
means the file is limited to one page only.
cpumap_print_to_pagebuf() API works terribly well for this kind of
normal attribute with buf parameter and without offset, count:
static inline ssize_t
cpumap_print_to_pagebuf(bool list, char *buf, const struct cpumask *mask)
{
return bitmap_print_to_pagebuf(list, buf, cpumask_bits(mask),
nr_cpu_ids);
}
The problem is once we have many cpus, we have a chance to make bitmask
or list more than one page. Especially for list, it could be as complex
as 0,3,5,7,9,...... We have no simple way to know it exact size.
It turns out bin_attribute is a way to break this limit. bin_attribute
has show entry as below:
static ssize_t
example_bin_attribute_show(struct file *filp, struct kobject *kobj,
struct bin_attribute *attr, char *buf,
loff_t offset, size_t count)
{
...
}
With the new offset and count parameters, this makes sysfs ABI be able
to support file size more than one page. For example, offset could be
>= 4096.
This patch introduces cpumap_print_bitmask/list_to_buf() and their bitmap
infrastructure bitmap_print_bitmask/list_to_buf() so that those drivers
can move to bin_attribute to support large bitmask and list. At the same
time, we have to pass those corresponding parameters such as offset, count
from bin_attribute to this new API.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Stefano Brivio <sbrivio@redhat.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: "Ma, Jianpeng" <jianpeng.ma@intel.com>
Cc: Yury Norov <yury.norov@gmail.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
Link: https://lore.kernel.org/r/20210806110251.560-2-song.bao.hua@hisilicon.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-06 14:02:47 +03:00
*
* The bitmap_print_to_pagebuf ( ) is used indirectly via its cpumap wrapper
* cpumap_print_to_pagebuf ( ) or directly by drivers to export hexadecimal
* bitmask and decimal list to userspace by sysfs ABI .
* Drivers might be using a normal attribute for this kind of ABIs . A
2022-03-26 13:41:46 +03:00
* normal attribute typically has show entry as below : :
*
* static ssize_t example_attribute_show ( struct device * dev ,
cpumask: introduce cpumap_print_list/bitmask_to_buf to support large bitmask and list
The existing cpumap_print_to_pagebuf() is used by cpu topology and other
drivers to export hexadecimal bitmask and decimal list to userspace by
sysfs ABI.
Right now, those drivers are using a normal attribute for this kind of
ABIs. A normal attribute typically has show entry as below:
static ssize_t example_dev_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
...
return cpumap_print_to_pagebuf(true, buf, &pmu_mmdc->cpu);
}
show entry of attribute has no offset and count parameters and this
means the file is limited to one page only.
cpumap_print_to_pagebuf() API works terribly well for this kind of
normal attribute with buf parameter and without offset, count:
static inline ssize_t
cpumap_print_to_pagebuf(bool list, char *buf, const struct cpumask *mask)
{
return bitmap_print_to_pagebuf(list, buf, cpumask_bits(mask),
nr_cpu_ids);
}
The problem is once we have many cpus, we have a chance to make bitmask
or list more than one page. Especially for list, it could be as complex
as 0,3,5,7,9,...... We have no simple way to know it exact size.
It turns out bin_attribute is a way to break this limit. bin_attribute
has show entry as below:
static ssize_t
example_bin_attribute_show(struct file *filp, struct kobject *kobj,
struct bin_attribute *attr, char *buf,
loff_t offset, size_t count)
{
...
}
With the new offset and count parameters, this makes sysfs ABI be able
to support file size more than one page. For example, offset could be
>= 4096.
This patch introduces cpumap_print_bitmask/list_to_buf() and their bitmap
infrastructure bitmap_print_bitmask/list_to_buf() so that those drivers
can move to bin_attribute to support large bitmask and list. At the same
time, we have to pass those corresponding parameters such as offset, count
from bin_attribute to this new API.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Stefano Brivio <sbrivio@redhat.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: "Ma, Jianpeng" <jianpeng.ma@intel.com>
Cc: Yury Norov <yury.norov@gmail.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
Link: https://lore.kernel.org/r/20210806110251.560-2-song.bao.hua@hisilicon.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-06 14:02:47 +03:00
* struct device_attribute * attr , char * buf )
2022-03-26 13:41:46 +03:00
* {
cpumask: introduce cpumap_print_list/bitmask_to_buf to support large bitmask and list
The existing cpumap_print_to_pagebuf() is used by cpu topology and other
drivers to export hexadecimal bitmask and decimal list to userspace by
sysfs ABI.
Right now, those drivers are using a normal attribute for this kind of
ABIs. A normal attribute typically has show entry as below:
static ssize_t example_dev_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
...
return cpumap_print_to_pagebuf(true, buf, &pmu_mmdc->cpu);
}
show entry of attribute has no offset and count parameters and this
means the file is limited to one page only.
cpumap_print_to_pagebuf() API works terribly well for this kind of
normal attribute with buf parameter and without offset, count:
static inline ssize_t
cpumap_print_to_pagebuf(bool list, char *buf, const struct cpumask *mask)
{
return bitmap_print_to_pagebuf(list, buf, cpumask_bits(mask),
nr_cpu_ids);
}
The problem is once we have many cpus, we have a chance to make bitmask
or list more than one page. Especially for list, it could be as complex
as 0,3,5,7,9,...... We have no simple way to know it exact size.
It turns out bin_attribute is a way to break this limit. bin_attribute
has show entry as below:
static ssize_t
example_bin_attribute_show(struct file *filp, struct kobject *kobj,
struct bin_attribute *attr, char *buf,
loff_t offset, size_t count)
{
...
}
With the new offset and count parameters, this makes sysfs ABI be able
to support file size more than one page. For example, offset could be
>= 4096.
This patch introduces cpumap_print_bitmask/list_to_buf() and their bitmap
infrastructure bitmap_print_bitmask/list_to_buf() so that those drivers
can move to bin_attribute to support large bitmask and list. At the same
time, we have to pass those corresponding parameters such as offset, count
from bin_attribute to this new API.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Stefano Brivio <sbrivio@redhat.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: "Ma, Jianpeng" <jianpeng.ma@intel.com>
Cc: Yury Norov <yury.norov@gmail.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
Link: https://lore.kernel.org/r/20210806110251.560-2-song.bao.hua@hisilicon.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-06 14:02:47 +03:00
* . . .
* return bitmap_print_to_pagebuf ( true , buf , & mask , nr_trig_max ) ;
2022-03-26 13:41:46 +03:00
* }
*
cpumask: introduce cpumap_print_list/bitmask_to_buf to support large bitmask and list
The existing cpumap_print_to_pagebuf() is used by cpu topology and other
drivers to export hexadecimal bitmask and decimal list to userspace by
sysfs ABI.
Right now, those drivers are using a normal attribute for this kind of
ABIs. A normal attribute typically has show entry as below:
static ssize_t example_dev_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
...
return cpumap_print_to_pagebuf(true, buf, &pmu_mmdc->cpu);
}
show entry of attribute has no offset and count parameters and this
means the file is limited to one page only.
cpumap_print_to_pagebuf() API works terribly well for this kind of
normal attribute with buf parameter and without offset, count:
static inline ssize_t
cpumap_print_to_pagebuf(bool list, char *buf, const struct cpumask *mask)
{
return bitmap_print_to_pagebuf(list, buf, cpumask_bits(mask),
nr_cpu_ids);
}
The problem is once we have many cpus, we have a chance to make bitmask
or list more than one page. Especially for list, it could be as complex
as 0,3,5,7,9,...... We have no simple way to know it exact size.
It turns out bin_attribute is a way to break this limit. bin_attribute
has show entry as below:
static ssize_t
example_bin_attribute_show(struct file *filp, struct kobject *kobj,
struct bin_attribute *attr, char *buf,
loff_t offset, size_t count)
{
...
}
With the new offset and count parameters, this makes sysfs ABI be able
to support file size more than one page. For example, offset could be
>= 4096.
This patch introduces cpumap_print_bitmask/list_to_buf() and their bitmap
infrastructure bitmap_print_bitmask/list_to_buf() so that those drivers
can move to bin_attribute to support large bitmask and list. At the same
time, we have to pass those corresponding parameters such as offset, count
from bin_attribute to this new API.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Stefano Brivio <sbrivio@redhat.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: "Ma, Jianpeng" <jianpeng.ma@intel.com>
Cc: Yury Norov <yury.norov@gmail.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
Link: https://lore.kernel.org/r/20210806110251.560-2-song.bao.hua@hisilicon.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-06 14:02:47 +03:00
* show entry of attribute has no offset and count parameters and this
* means the file is limited to one page only .
* bitmap_print_to_pagebuf ( ) API works terribly well for this kind of
2022-03-26 13:41:46 +03:00
* normal attribute with buf parameter and without offset , count : :
*
* bitmap_print_to_pagebuf ( bool list , char * buf , const unsigned long * maskp ,
cpumask: introduce cpumap_print_list/bitmask_to_buf to support large bitmask and list
The existing cpumap_print_to_pagebuf() is used by cpu topology and other
drivers to export hexadecimal bitmask and decimal list to userspace by
sysfs ABI.
Right now, those drivers are using a normal attribute for this kind of
ABIs. A normal attribute typically has show entry as below:
static ssize_t example_dev_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
...
return cpumap_print_to_pagebuf(true, buf, &pmu_mmdc->cpu);
}
show entry of attribute has no offset and count parameters and this
means the file is limited to one page only.
cpumap_print_to_pagebuf() API works terribly well for this kind of
normal attribute with buf parameter and without offset, count:
static inline ssize_t
cpumap_print_to_pagebuf(bool list, char *buf, const struct cpumask *mask)
{
return bitmap_print_to_pagebuf(list, buf, cpumask_bits(mask),
nr_cpu_ids);
}
The problem is once we have many cpus, we have a chance to make bitmask
or list more than one page. Especially for list, it could be as complex
as 0,3,5,7,9,...... We have no simple way to know it exact size.
It turns out bin_attribute is a way to break this limit. bin_attribute
has show entry as below:
static ssize_t
example_bin_attribute_show(struct file *filp, struct kobject *kobj,
struct bin_attribute *attr, char *buf,
loff_t offset, size_t count)
{
...
}
With the new offset and count parameters, this makes sysfs ABI be able
to support file size more than one page. For example, offset could be
>= 4096.
This patch introduces cpumap_print_bitmask/list_to_buf() and their bitmap
infrastructure bitmap_print_bitmask/list_to_buf() so that those drivers
can move to bin_attribute to support large bitmask and list. At the same
time, we have to pass those corresponding parameters such as offset, count
from bin_attribute to this new API.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Stefano Brivio <sbrivio@redhat.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: "Ma, Jianpeng" <jianpeng.ma@intel.com>
Cc: Yury Norov <yury.norov@gmail.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
Link: https://lore.kernel.org/r/20210806110251.560-2-song.bao.hua@hisilicon.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-06 14:02:47 +03:00
* int nmaskbits )
2022-03-26 13:41:46 +03:00
* {
* }
*
cpumask: introduce cpumap_print_list/bitmask_to_buf to support large bitmask and list
The existing cpumap_print_to_pagebuf() is used by cpu topology and other
drivers to export hexadecimal bitmask and decimal list to userspace by
sysfs ABI.
Right now, those drivers are using a normal attribute for this kind of
ABIs. A normal attribute typically has show entry as below:
static ssize_t example_dev_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
...
return cpumap_print_to_pagebuf(true, buf, &pmu_mmdc->cpu);
}
show entry of attribute has no offset and count parameters and this
means the file is limited to one page only.
cpumap_print_to_pagebuf() API works terribly well for this kind of
normal attribute with buf parameter and without offset, count:
static inline ssize_t
cpumap_print_to_pagebuf(bool list, char *buf, const struct cpumask *mask)
{
return bitmap_print_to_pagebuf(list, buf, cpumask_bits(mask),
nr_cpu_ids);
}
The problem is once we have many cpus, we have a chance to make bitmask
or list more than one page. Especially for list, it could be as complex
as 0,3,5,7,9,...... We have no simple way to know it exact size.
It turns out bin_attribute is a way to break this limit. bin_attribute
has show entry as below:
static ssize_t
example_bin_attribute_show(struct file *filp, struct kobject *kobj,
struct bin_attribute *attr, char *buf,
loff_t offset, size_t count)
{
...
}
With the new offset and count parameters, this makes sysfs ABI be able
to support file size more than one page. For example, offset could be
>= 4096.
This patch introduces cpumap_print_bitmask/list_to_buf() and their bitmap
infrastructure bitmap_print_bitmask/list_to_buf() so that those drivers
can move to bin_attribute to support large bitmask and list. At the same
time, we have to pass those corresponding parameters such as offset, count
from bin_attribute to this new API.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Stefano Brivio <sbrivio@redhat.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: "Ma, Jianpeng" <jianpeng.ma@intel.com>
Cc: Yury Norov <yury.norov@gmail.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
Link: https://lore.kernel.org/r/20210806110251.560-2-song.bao.hua@hisilicon.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-06 14:02:47 +03:00
* The problem is once we have a large bitmap , we have a chance to get a
* bitmask or list more than one page . Especially for list , it could be
* as complex as 0 , 3 , 5 , 7 , 9 , . . . We have no simple way to know it exact size .
* It turns out bin_attribute is a way to break this limit . bin_attribute
2022-03-26 13:41:46 +03:00
* has show entry as below : :
*
* static ssize_t
* example_bin_attribute_show ( struct file * filp , struct kobject * kobj ,
cpumask: introduce cpumap_print_list/bitmask_to_buf to support large bitmask and list
The existing cpumap_print_to_pagebuf() is used by cpu topology and other
drivers to export hexadecimal bitmask and decimal list to userspace by
sysfs ABI.
Right now, those drivers are using a normal attribute for this kind of
ABIs. A normal attribute typically has show entry as below:
static ssize_t example_dev_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
...
return cpumap_print_to_pagebuf(true, buf, &pmu_mmdc->cpu);
}
show entry of attribute has no offset and count parameters and this
means the file is limited to one page only.
cpumap_print_to_pagebuf() API works terribly well for this kind of
normal attribute with buf parameter and without offset, count:
static inline ssize_t
cpumap_print_to_pagebuf(bool list, char *buf, const struct cpumask *mask)
{
return bitmap_print_to_pagebuf(list, buf, cpumask_bits(mask),
nr_cpu_ids);
}
The problem is once we have many cpus, we have a chance to make bitmask
or list more than one page. Especially for list, it could be as complex
as 0,3,5,7,9,...... We have no simple way to know it exact size.
It turns out bin_attribute is a way to break this limit. bin_attribute
has show entry as below:
static ssize_t
example_bin_attribute_show(struct file *filp, struct kobject *kobj,
struct bin_attribute *attr, char *buf,
loff_t offset, size_t count)
{
...
}
With the new offset and count parameters, this makes sysfs ABI be able
to support file size more than one page. For example, offset could be
>= 4096.
This patch introduces cpumap_print_bitmask/list_to_buf() and their bitmap
infrastructure bitmap_print_bitmask/list_to_buf() so that those drivers
can move to bin_attribute to support large bitmask and list. At the same
time, we have to pass those corresponding parameters such as offset, count
from bin_attribute to this new API.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Stefano Brivio <sbrivio@redhat.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: "Ma, Jianpeng" <jianpeng.ma@intel.com>
Cc: Yury Norov <yury.norov@gmail.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
Link: https://lore.kernel.org/r/20210806110251.560-2-song.bao.hua@hisilicon.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-06 14:02:47 +03:00
* struct bin_attribute * attr , char * buf ,
* loff_t offset , size_t count )
2022-03-26 13:41:46 +03:00
* {
cpumask: introduce cpumap_print_list/bitmask_to_buf to support large bitmask and list
The existing cpumap_print_to_pagebuf() is used by cpu topology and other
drivers to export hexadecimal bitmask and decimal list to userspace by
sysfs ABI.
Right now, those drivers are using a normal attribute for this kind of
ABIs. A normal attribute typically has show entry as below:
static ssize_t example_dev_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
...
return cpumap_print_to_pagebuf(true, buf, &pmu_mmdc->cpu);
}
show entry of attribute has no offset and count parameters and this
means the file is limited to one page only.
cpumap_print_to_pagebuf() API works terribly well for this kind of
normal attribute with buf parameter and without offset, count:
static inline ssize_t
cpumap_print_to_pagebuf(bool list, char *buf, const struct cpumask *mask)
{
return bitmap_print_to_pagebuf(list, buf, cpumask_bits(mask),
nr_cpu_ids);
}
The problem is once we have many cpus, we have a chance to make bitmask
or list more than one page. Especially for list, it could be as complex
as 0,3,5,7,9,...... We have no simple way to know it exact size.
It turns out bin_attribute is a way to break this limit. bin_attribute
has show entry as below:
static ssize_t
example_bin_attribute_show(struct file *filp, struct kobject *kobj,
struct bin_attribute *attr, char *buf,
loff_t offset, size_t count)
{
...
}
With the new offset and count parameters, this makes sysfs ABI be able
to support file size more than one page. For example, offset could be
>= 4096.
This patch introduces cpumap_print_bitmask/list_to_buf() and their bitmap
infrastructure bitmap_print_bitmask/list_to_buf() so that those drivers
can move to bin_attribute to support large bitmask and list. At the same
time, we have to pass those corresponding parameters such as offset, count
from bin_attribute to this new API.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Stefano Brivio <sbrivio@redhat.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: "Ma, Jianpeng" <jianpeng.ma@intel.com>
Cc: Yury Norov <yury.norov@gmail.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
Link: https://lore.kernel.org/r/20210806110251.560-2-song.bao.hua@hisilicon.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-06 14:02:47 +03:00
* . . .
2022-03-26 13:41:46 +03:00
* }
*
cpumask: introduce cpumap_print_list/bitmask_to_buf to support large bitmask and list
The existing cpumap_print_to_pagebuf() is used by cpu topology and other
drivers to export hexadecimal bitmask and decimal list to userspace by
sysfs ABI.
Right now, those drivers are using a normal attribute for this kind of
ABIs. A normal attribute typically has show entry as below:
static ssize_t example_dev_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
...
return cpumap_print_to_pagebuf(true, buf, &pmu_mmdc->cpu);
}
show entry of attribute has no offset and count parameters and this
means the file is limited to one page only.
cpumap_print_to_pagebuf() API works terribly well for this kind of
normal attribute with buf parameter and without offset, count:
static inline ssize_t
cpumap_print_to_pagebuf(bool list, char *buf, const struct cpumask *mask)
{
return bitmap_print_to_pagebuf(list, buf, cpumask_bits(mask),
nr_cpu_ids);
}
The problem is once we have many cpus, we have a chance to make bitmask
or list more than one page. Especially for list, it could be as complex
as 0,3,5,7,9,...... We have no simple way to know it exact size.
It turns out bin_attribute is a way to break this limit. bin_attribute
has show entry as below:
static ssize_t
example_bin_attribute_show(struct file *filp, struct kobject *kobj,
struct bin_attribute *attr, char *buf,
loff_t offset, size_t count)
{
...
}
With the new offset and count parameters, this makes sysfs ABI be able
to support file size more than one page. For example, offset could be
>= 4096.
This patch introduces cpumap_print_bitmask/list_to_buf() and their bitmap
infrastructure bitmap_print_bitmask/list_to_buf() so that those drivers
can move to bin_attribute to support large bitmask and list. At the same
time, we have to pass those corresponding parameters such as offset, count
from bin_attribute to this new API.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Stefano Brivio <sbrivio@redhat.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: "Ma, Jianpeng" <jianpeng.ma@intel.com>
Cc: Yury Norov <yury.norov@gmail.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
Link: https://lore.kernel.org/r/20210806110251.560-2-song.bao.hua@hisilicon.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-06 14:02:47 +03:00
* With the new offset and count parameters , this makes sysfs ABI be able
* to support file size more than one page . For example , offset could be
* > = 4096.
* bitmap_print_bitmask_to_buf ( ) , bitmap_print_list_to_buf ( ) wit their
* cpumap wrapper cpumap_print_bitmask_to_buf ( ) , cpumap_print_list_to_buf ( )
* make those drivers be able to support large bitmask and list after they
* move to use bin_attribute . In result , we have to pass the corresponding
* parameters such as off , count from bin_attribute show entry to this API .
*
* The role of cpumap_print_bitmask_to_buf ( ) and cpumap_print_list_to_buf ( )
* is similar with cpumap_print_to_pagebuf ( ) , the difference is that
* bitmap_print_to_pagebuf ( ) mainly serves sysfs attribute with the assumption
* the destination buffer is exactly one page and won ' t be more than one page .
* cpumap_print_bitmask_to_buf ( ) and cpumap_print_list_to_buf ( ) , on the other
* hand , mainly serves bin_attribute which doesn ' t work with exact one page ,
* and it can break the size limit of converted decimal list and hexadecimal
* bitmask .
*
2021-08-06 14:02:51 +03:00
* WARNING !
*
* This function is not a replacement for sprintf ( ) or bitmap_print_to_pagebuf ( ) .
* It is intended to workaround sysfs limitations discussed above and should be
* used carefully in general case for the following reasons :
2022-03-26 13:41:46 +03:00
*
2021-08-06 14:02:51 +03:00
* - Time complexity is O ( nbits ^ 2 / count ) , comparing to O ( nbits ) for snprintf ( ) .
* - Memory complexity is O ( nbits ) , comparing to O ( 1 ) for snprintf ( ) .
* - @ off and @ count are NOT offset and number of bits to print .
* - If printing part of bitmap as list , the resulting string is not a correct
* list representation of bitmap . Particularly , some bits within or out of
* related interval may be erroneously set or unset . The format of the string
* may be broken , so bitmap_parselist - like parser may fail parsing it .
* - If printing the whole bitmap as list by parts , user must ensure the order
* of calls of the function such that the offset is incremented linearly .
* - If printing the whole bitmap as list by parts , user must keep bitmap
* unchanged between the very first and very last call . Otherwise concatenated
* result may be incorrect , and format may be broken .
*
cpumask: introduce cpumap_print_list/bitmask_to_buf to support large bitmask and list
The existing cpumap_print_to_pagebuf() is used by cpu topology and other
drivers to export hexadecimal bitmask and decimal list to userspace by
sysfs ABI.
Right now, those drivers are using a normal attribute for this kind of
ABIs. A normal attribute typically has show entry as below:
static ssize_t example_dev_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
...
return cpumap_print_to_pagebuf(true, buf, &pmu_mmdc->cpu);
}
show entry of attribute has no offset and count parameters and this
means the file is limited to one page only.
cpumap_print_to_pagebuf() API works terribly well for this kind of
normal attribute with buf parameter and without offset, count:
static inline ssize_t
cpumap_print_to_pagebuf(bool list, char *buf, const struct cpumask *mask)
{
return bitmap_print_to_pagebuf(list, buf, cpumask_bits(mask),
nr_cpu_ids);
}
The problem is once we have many cpus, we have a chance to make bitmask
or list more than one page. Especially for list, it could be as complex
as 0,3,5,7,9,...... We have no simple way to know it exact size.
It turns out bin_attribute is a way to break this limit. bin_attribute
has show entry as below:
static ssize_t
example_bin_attribute_show(struct file *filp, struct kobject *kobj,
struct bin_attribute *attr, char *buf,
loff_t offset, size_t count)
{
...
}
With the new offset and count parameters, this makes sysfs ABI be able
to support file size more than one page. For example, offset could be
>= 4096.
This patch introduces cpumap_print_bitmask/list_to_buf() and their bitmap
infrastructure bitmap_print_bitmask/list_to_buf() so that those drivers
can move to bin_attribute to support large bitmask and list. At the same
time, we have to pass those corresponding parameters such as offset, count
from bin_attribute to this new API.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Stefano Brivio <sbrivio@redhat.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: "Ma, Jianpeng" <jianpeng.ma@intel.com>
Cc: Yury Norov <yury.norov@gmail.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
Link: https://lore.kernel.org/r/20210806110251.560-2-song.bao.hua@hisilicon.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-06 14:02:47 +03:00
* Returns the number of characters actually printed to @ buf
*/
int bitmap_print_bitmask_to_buf ( char * buf , const unsigned long * maskp ,
int nmaskbits , loff_t off , size_t count )
{
return bitmap_print_to_buf ( false , buf , maskp , nmaskbits , off , count ) ;
}
EXPORT_SYMBOL ( bitmap_print_bitmask_to_buf ) ;
/**
* bitmap_print_list_to_buf - convert bitmap to decimal list format ASCII string
2022-03-24 02:05:53 +03:00
* @ buf : buffer into which string is placed
* @ maskp : pointer to bitmap to convert
* @ nmaskbits : size of bitmap , in bits
* @ off : in the string from which we are copying , We copy to @ buf
* @ count : the maximum number of bytes to print
cpumask: introduce cpumap_print_list/bitmask_to_buf to support large bitmask and list
The existing cpumap_print_to_pagebuf() is used by cpu topology and other
drivers to export hexadecimal bitmask and decimal list to userspace by
sysfs ABI.
Right now, those drivers are using a normal attribute for this kind of
ABIs. A normal attribute typically has show entry as below:
static ssize_t example_dev_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
...
return cpumap_print_to_pagebuf(true, buf, &pmu_mmdc->cpu);
}
show entry of attribute has no offset and count parameters and this
means the file is limited to one page only.
cpumap_print_to_pagebuf() API works terribly well for this kind of
normal attribute with buf parameter and without offset, count:
static inline ssize_t
cpumap_print_to_pagebuf(bool list, char *buf, const struct cpumask *mask)
{
return bitmap_print_to_pagebuf(list, buf, cpumask_bits(mask),
nr_cpu_ids);
}
The problem is once we have many cpus, we have a chance to make bitmask
or list more than one page. Especially for list, it could be as complex
as 0,3,5,7,9,...... We have no simple way to know it exact size.
It turns out bin_attribute is a way to break this limit. bin_attribute
has show entry as below:
static ssize_t
example_bin_attribute_show(struct file *filp, struct kobject *kobj,
struct bin_attribute *attr, char *buf,
loff_t offset, size_t count)
{
...
}
With the new offset and count parameters, this makes sysfs ABI be able
to support file size more than one page. For example, offset could be
>= 4096.
This patch introduces cpumap_print_bitmask/list_to_buf() and their bitmap
infrastructure bitmap_print_bitmask/list_to_buf() so that those drivers
can move to bin_attribute to support large bitmask and list. At the same
time, we have to pass those corresponding parameters such as offset, count
from bin_attribute to this new API.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Stefano Brivio <sbrivio@redhat.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: "Ma, Jianpeng" <jianpeng.ma@intel.com>
Cc: Yury Norov <yury.norov@gmail.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
Link: https://lore.kernel.org/r/20210806110251.560-2-song.bao.hua@hisilicon.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-06 14:02:47 +03:00
*
* Everything is same with the above bitmap_print_bitmask_to_buf ( ) except
* the print format .
*/
int bitmap_print_list_to_buf ( char * buf , const unsigned long * maskp ,
int nmaskbits , loff_t off , size_t count )
{
return bitmap_print_to_buf ( true , buf , maskp , nmaskbits , off , count ) ;
}
EXPORT_SYMBOL ( bitmap_print_list_to_buf ) ;
2019-05-15 01:43:14 +03:00
/*
* Region 9 - 38 : 4 / 10 describes the following bitmap structure :
2021-02-21 11:08:23 +03:00
* 0 9 12 18 38 N
* . . . . . . . . . * * * * . . . . . . * * * * . . . . . . * * * * . . . . . . . . . . . . . . . . . .
* ^ ^ ^ ^ ^
* start off group_len end nbits
2019-05-15 01:43:14 +03:00
*/
struct region {
unsigned int start ;
unsigned int off ;
unsigned int group_len ;
unsigned int end ;
2021-02-21 11:08:23 +03:00
unsigned int nbits ;
2019-05-15 01:43:14 +03:00
} ;
2021-02-21 11:08:24 +03:00
static void bitmap_set_region ( const struct region * r , unsigned long * bitmap )
2019-05-15 01:43:14 +03:00
{
unsigned int start ;
for ( start = r - > start ; start < = r - > end ; start + = r - > group_len )
bitmap_set ( bitmap , start , min ( r - > end - start + 1 , r - > off ) ) ;
}
static int bitmap_check_region ( const struct region * r )
{
if ( r - > start > r - > end | | r - > group_len = = 0 | | r - > off > r - > group_len )
return - EINVAL ;
2021-02-21 11:08:24 +03:00
if ( r - > end > = r - > nbits )
return - ERANGE ;
2019-05-15 01:43:14 +03:00
return 0 ;
}
2021-02-21 11:08:25 +03:00
static const char * bitmap_getnum ( const char * str , unsigned int * num ,
unsigned int lastbit )
2019-05-15 01:43:14 +03:00
{
unsigned long long n ;
unsigned int len ;
2021-02-21 11:08:25 +03:00
if ( str [ 0 ] = = ' N ' ) {
* num = lastbit ;
return str + 1 ;
}
2019-05-15 01:43:14 +03:00
len = _parse_integer ( str , 10 , & n ) ;
if ( ! len )
return ERR_PTR ( - EINVAL ) ;
if ( len & KSTRTOX_OVERFLOW | | n ! = ( unsigned int ) n )
return ERR_PTR ( - EOVERFLOW ) ;
* num = n ;
return str + len ;
}
static inline bool end_of_str ( char c )
{
return c = = ' \0 ' | | c = = ' \n ' ;
}
static inline bool __end_of_region ( char c )
{
return isspace ( c ) | | c = = ' , ' ;
}
static inline bool end_of_region ( char c )
{
return __end_of_region ( c ) | | end_of_str ( c ) ;
}
/*
2020-03-31 03:22:11 +03:00
* The format allows commas and whitespaces at the beginning
2019-05-15 01:43:14 +03:00
* of the region .
*/
static const char * bitmap_find_region ( const char * str )
{
while ( __end_of_region ( * str ) )
str + + ;
return end_of_str ( * str ) ? NULL : str ;
}
2020-02-04 04:37:34 +03:00
static const char * bitmap_find_region_reverse ( const char * start , const char * end )
{
while ( start < = end & & __end_of_region ( * end ) )
end - - ;
return end ;
}
2019-05-15 01:43:14 +03:00
static const char * bitmap_parse_region ( const char * str , struct region * r )
{
2021-02-21 11:08:25 +03:00
unsigned int lastbit = r - > nbits - 1 ;
2021-04-21 06:13:25 +03:00
if ( ! strncasecmp ( str , " all " , 3 ) ) {
r - > start = 0 ;
r - > end = lastbit ;
str + = 3 ;
goto check_pattern ;
}
2021-02-21 11:08:25 +03:00
str = bitmap_getnum ( str , & r - > start , lastbit ) ;
2019-05-15 01:43:14 +03:00
if ( IS_ERR ( str ) )
return str ;
if ( end_of_region ( * str ) )
goto no_end ;
if ( * str ! = ' - ' )
return ERR_PTR ( - EINVAL ) ;
2021-02-21 11:08:25 +03:00
str = bitmap_getnum ( str + 1 , & r - > end , lastbit ) ;
2019-05-15 01:43:14 +03:00
if ( IS_ERR ( str ) )
return str ;
2021-04-21 06:13:25 +03:00
check_pattern :
2019-05-15 01:43:14 +03:00
if ( end_of_region ( * str ) )
goto no_pattern ;
if ( * str ! = ' : ' )
return ERR_PTR ( - EINVAL ) ;
2021-02-21 11:08:25 +03:00
str = bitmap_getnum ( str + 1 , & r - > off , lastbit ) ;
2019-05-15 01:43:14 +03:00
if ( IS_ERR ( str ) )
return str ;
if ( * str ! = ' / ' )
return ERR_PTR ( - EINVAL ) ;
2021-02-21 11:08:25 +03:00
return bitmap_getnum ( str + 1 , & r - > group_len , lastbit ) ;
2019-05-15 01:43:14 +03:00
no_end :
r - > end = r - > start ;
no_pattern :
r - > off = r - > end + 1 ;
r - > group_len = r - > end + 1 ;
return end_of_str ( * str ) ? NULL : str ;
}
2005-04-17 02:20:36 +04:00
/**
2019-05-15 01:43:14 +03:00
* bitmap_parselist - convert list format ASCII string to bitmap
* @ buf : read user string from this buffer ; must be terminated
* with a \ 0 or \ n .
2006-06-25 16:48:57 +04:00
* @ maskp : write resulting mask here
2005-04-17 02:20:36 +04: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 23:51:35 +03: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
2021-02-21 11:08:25 +03:00
* The value ' N ' can be used as a dynamically substituted token for the
* maximum allowed value ; i . e ( nmaskbits - 1 ) . Keep in mind that it is
* dynamic , so if system changes cause the bitmap width to change , such
* as more cores in a CPU list , then any ranges using N will also change .
2005-04-17 02:20:36 +04:00
*
2017-03-30 23:11:35 +03:00
* Returns : 0 on success , - errno on invalid input strings . Error values :
*
2019-05-15 01:43:14 +03:00
* - ` ` - EINVAL ` ` : wrong region format
2017-03-30 23:11:35 +03:00
* - ` ` - EINVAL ` ` : invalid character in string
* - ` ` - ERANGE ` ` : bit number specified too large for mask
2019-05-15 01:43:14 +03:00
* - ` ` - EOVERFLOW ` ` : integer overflow in the input parameters
2005-04-17 02:20:36 +04:00
*/
2019-05-15 01:43:14 +03:00
int bitmap_parselist ( const char * buf , unsigned long * maskp , int nmaskbits )
2005-04-17 02:20:36 +04:00
{
2019-05-15 01:43:14 +03:00
struct region r ;
long ret ;
2005-04-17 02:20:36 +04:00
2021-02-21 11:08:23 +03:00
r . nbits = nmaskbits ;
bitmap_zero ( maskp , r . nbits ) ;
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 04:13:12 +04:00
2019-05-15 01:43:14 +03:00
while ( buf ) {
buf = bitmap_find_region ( buf ) ;
if ( buf = = NULL )
return 0 ;
2016-10-11 23:51:35 +03:00
2019-05-15 01:43:14 +03:00
buf = bitmap_parse_region ( buf , & r ) ;
if ( IS_ERR ( buf ) )
return PTR_ERR ( buf ) ;
2016-10-11 23:51:35 +03:00
2019-05-15 01:43:14 +03:00
ret = bitmap_check_region ( & r ) ;
if ( ret )
return ret ;
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 04:13:12 +04:00
2021-02-21 11:08:24 +03:00
bitmap_set_region ( & r , maskp ) ;
2019-05-15 01:43:14 +03: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 04:13:12 +04:00
2005-04-17 02:20:36 +04:00
return 0 ;
}
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 04:13:12 +04:00
/**
2022-03-24 02:05:53 +03:00
* bitmap_parselist_user ( ) - convert user buffer ' s list format ASCII
* string to bitmap
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 04:13:12 +04: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_parselist ( ) , providing it with user buffer .
*/
int bitmap_parselist_user ( const char __user * ubuf ,
unsigned int ulen , unsigned long * maskp ,
int nmaskbits )
{
2019-05-15 01:43:11 +03:00
char * buf ;
int ret ;
buf = memdup_user_nul ( ubuf , ulen ) ;
if ( IS_ERR ( buf ) )
return PTR_ERR ( buf ) ;
ret = bitmap_parselist ( buf , maskp , nmaskbits ) ;
kfree ( buf ) ;
return ret ;
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 04:13:12 +04:00
}
EXPORT_SYMBOL ( bitmap_parselist_user ) ;
2020-02-04 04:37:34 +03:00
static const char * bitmap_get_x32_reverse ( const char * start ,
const char * end , u32 * num )
{
u32 ret = 0 ;
int c , i ;
for ( i = 0 ; i < 32 ; i + = 4 ) {
c = hex_to_bin ( * end - - ) ;
if ( c < 0 )
return ERR_PTR ( - EINVAL ) ;
ret | = c < < i ;
if ( start > end | | __end_of_region ( * end ) )
goto out ;
}
if ( hex_to_bin ( * end - - ) > = 0 )
return ERR_PTR ( - EOVERFLOW ) ;
out :
* num = ret ;
return end ;
}
/**
* bitmap_parse - convert an ASCII hex string into a bitmap .
* @ start : pointer to buffer containing string .
* @ buflen : buffer size in bytes . If string is smaller than this
* then it must be terminated with a \ 0 or \ n . In that case ,
* UINT_MAX may be provided instead of string length .
* @ 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
* than 32 bits ( % - EOVERFLOW ) , and if a chunk specifies a smaller value
* then leading 0 - bits are prepended . % - EINVAL is returned for illegal
* characters . Grouping such as " 1,,5 " , " ,44 " , " , " or " " is allowed .
* Leading , embedded and trailing whitespace accepted .
*/
int bitmap_parse ( const char * start , unsigned int buflen ,
unsigned long * maskp , int nmaskbits )
{
const char * end = strnchrnul ( start , buflen , ' \n ' ) - 1 ;
int chunks = BITS_TO_U32 ( nmaskbits ) ;
u32 * bitmap = ( u32 * ) maskp ;
int unset_bit ;
2020-06-11 04:41:41 +03:00
int chunk ;
2020-02-04 04:37:34 +03:00
2020-06-11 04:41:41 +03:00
for ( chunk = 0 ; ; chunk + + ) {
2020-02-04 04:37:34 +03:00
end = bitmap_find_region_reverse ( start , end ) ;
if ( start > end )
break ;
if ( ! chunks - - )
return - EOVERFLOW ;
2020-06-11 04:41:41 +03:00
# if defined(CONFIG_64BIT) && defined(__BIG_ENDIAN)
end = bitmap_get_x32_reverse ( start , end , & bitmap [ chunk ^ 1 ] ) ;
# else
end = bitmap_get_x32_reverse ( start , end , & bitmap [ chunk ] ) ;
# endif
2020-02-04 04:37:34 +03:00
if ( IS_ERR ( end ) )
return PTR_ERR ( end ) ;
}
unset_bit = ( BITS_TO_U32 ( nmaskbits ) - chunks ) * 32 ;
if ( unset_bit < nmaskbits ) {
bitmap_clear ( maskp , unset_bit , nmaskbits - unset_bit ) ;
return 0 ;
}
if ( find_next_bit ( maskp , unset_bit , nmaskbits ) ! = unset_bit )
return - EOVERFLOW ;
return 0 ;
}
EXPORT_SYMBOL ( bitmap_parse ) ;
2007-02-10 12:45:59 +03:00
/**
2010-03-06 00:43:17 +03:00
* bitmap_pos_to_ord - find ordinal of set bit at given position in bitmap
2005-10-31 02:02:33 +03:00
* @ buf : pointer to a bitmap
2015-02-13 02:02:07 +03:00
* @ pos : a bit position in @ buf ( 0 < = @ pos < @ nbits )
* @ nbits : number of valid bit positions in @ buf
2005-10-31 02:02:33 +03:00
*
2015-02-13 02:02:07 +03:00
* Map the bit at position @ pos in @ buf ( of length @ nbits ) to the
2005-10-31 02:02:33 +03: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 12:01:46 +03:00
* is not a valid bit position , map to - 1.
2005-10-31 02:02:33 +03: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-07 03:10:14 +04:00
* and other @ pos values will get mapped to - 1. When @ pos value 7
2005-10-31 02:02:33 +03:00
* gets mapped to ( returns ) @ ord value 3 in this example , that means
* that bit 7 is the 3 rd ( starting with 0 th ) set bit in @ buf .
*
* The bit positions 0 through @ bits are valid positions in @ buf .
*/
2015-02-13 02:02:07 +03:00
static int bitmap_pos_to_ord ( const unsigned long * buf , unsigned int pos , unsigned int nbits )
2005-10-31 02:02:33 +03:00
{
2015-02-13 02:02:07 +03: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 12:01:46 +03:00
return - 1 ;
2005-10-31 02:02:33 +03:00
2015-02-13 02:02:07 +03:00
return __bitmap_weight ( buf , pos ) ;
2005-10-31 02:02:33 +03:00
}
/**
2010-03-06 00:43:17 +03:00
* bitmap_ord_to_pos - find position of n - th set bit in bitmap
2005-10-31 02:02:33 +03:00
* @ buf : pointer to bitmap
* @ ord : ordinal bit position ( n - th set bit , n > = 0 )
2015-02-13 02:02:10 +03:00
* @ nbits : number of valid bit positions in @ buf
2005-10-31 02:02:33 +03:00
*
* Map the ordinal offset of bit @ ord in @ buf to its position in @ buf .
2015-02-13 02:02:10 +03:00
* Value of @ ord should be in range 0 < = @ ord < weight ( buf ) . If @ ord
* > = weight ( buf ) , returns @ nbits .
2005-10-31 02:02:33 +03: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-13 02:02:10 +03:00
* and all other @ ord values returns @ nbits . When @ ord value 3
2005-10-31 02:02:33 +03:00
* gets mapped to ( returns ) @ pos value 7 in this example , that means
* that the 3 rd set bit ( starting with 0 th ) is at position 7 in @ buf .
*
2015-02-13 02:02:10 +03:00
* The bit positions 0 through @ nbits - 1 are valid positions in @ buf .
2005-10-31 02:02:33 +03:00
*/
2015-02-13 02:02:10 +03:00
unsigned int bitmap_ord_to_pos ( const unsigned long * buf , unsigned int ord , unsigned int nbits )
2005-10-31 02:02:33 +03:00
{
2015-02-13 02:02:10 +03:00
unsigned int pos ;
2005-10-31 02:02:33 +03:00
2015-02-13 02:02:10 +03:00
for ( pos = find_first_bit ( buf , nbits ) ;
pos < nbits & & ord ;
pos = find_next_bit ( buf , nbits , pos + 1 ) )
ord - - ;
2005-10-31 02:02:33 +03: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 12:01:46 +03:00
* @ src : subset to be remapped
2005-10-31 02:02:33 +03:00
* @ old : defines domain of map
* @ new : defines range of map
2015-02-13 02:02:13 +03:00
* @ nbits : number of bits in each of these bitmaps
2005-10-31 02:02:33 +03: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 12:01:46 +03: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-31 02:02:33 +03: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 12:01:46 +03:00
* The positions of unset bits in @ old are mapped to themselves
* ( the identify map ) .
2005-10-31 02:02:33 +03: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 12:01:46 +03: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-31 02:02:33 +03:00
*/
void bitmap_remap ( unsigned long * dst , const unsigned long * src ,
const unsigned long * old , const unsigned long * new ,
2015-02-13 02:02:13 +03:00
unsigned int nbits )
2005-10-31 02:02:33 +03:00
{
2015-02-13 02:02:13 +03:00
unsigned int oldbit , w ;
2005-10-31 02:02:33 +03:00
if ( dst = = src ) /* following doesn't handle inplace remaps */
return ;
2015-02-13 02:02:13 +03: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 12:01:46 +03:00
2015-02-13 02:02:13 +03:00
w = bitmap_weight ( new , nbits ) ;
for_each_set_bit ( oldbit , src , nbits ) {
int n = bitmap_pos_to_ord ( old , oldbit , nbits ) ;
2010-03-06 00:43:18 +03: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 12:01:46 +03:00
if ( n < 0 | | w = = 0 )
set_bit ( oldbit , dst ) ; /* identity map */
else
2015-02-13 02:02:13 +03:00
set_bit ( bitmap_ord_to_pos ( new , n % w , nbits ) , dst ) ;
2005-10-31 02:02:33 +03:00
}
}
2021-05-10 22:46:29 +03:00
EXPORT_SYMBOL ( bitmap_remap ) ;
2005-10-31 02:02:33 +03:00
/**
* bitmap_bitremap - Apply map defined by a pair of bitmaps to a single bit
2006-06-25 16:48:57 +04: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-31 02:02:33 +03: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 12:01:46 +03:00
* The positions of unset bits in @ old are mapped to themselves
* ( the identify map ) .
2005-10-31 02:02:33 +03: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 12:01:46 +03:00
* bit positions unchanged . So if say @ oldbit is 5 , then this routine
* returns 13.
2005-10-31 02:02:33 +03: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 12:01:46 +03: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-31 02:02:33 +03:00
}
2021-05-10 22:46:29 +03:00
EXPORT_SYMBOL ( bitmap_bitremap ) ;
2005-10-31 02:02:33 +03:00
2021-05-10 22:46:29 +03:00
# ifdef CONFIG_NUMA
mempolicy: add bitmap_onto() and bitmap_fold() operations
The following adds two more bitmap operators, bitmap_onto() and bitmap_fold(),
with the usual cpumask and nodemask wrappers.
The bitmap_onto() operator computes one bitmap relative to another. If the
n-th bit in the origin mask is set, then the m-th bit of the destination mask
will be set, where m is the position of the n-th set bit in the relative mask.
The bitmap_fold() operator folds a bitmap into a second that has bit m set iff
the input bitmap has some bit n set, where m == n mod sz, for the specified sz
value.
There are two substantive changes between this patch and its
predecessor bitmap_relative:
1) Renamed bitmap_relative() to be bitmap_onto().
2) Added bitmap_fold().
The essential motivation for bitmap_onto() is to provide a mechanism for
converting a cpuset-relative CPU or Node mask to an absolute mask. Cpuset
relative masks are written as if the current task were in a cpuset whose CPUs
or Nodes were just the consecutive ones numbered 0..N-1, for some N. The
bitmap_onto() operator is provided in anticipation of adding support for the
first such cpuset relative mask, by the mbind() and set_mempolicy() system
calls, using a planned flag of MPOL_F_RELATIVE_NODES. These bitmap operators
(and their nodemask wrappers, in particular) will be used in code that
converts the user specified cpuset relative memory policy to a specific system
node numbered policy, given the current mems_allowed of the tasks cpuset.
Such cpuset relative mempolicies will address two deficiencies
of the existing interface between cpusets and mempolicies:
1) A task cannot at present reliably establish a cpuset
relative mempolicy because there is an essential race
condition, in that the tasks cpuset may be changed in
between the time the task can query its cpuset placement,
and the time the task can issue the applicable mbind or
set_memplicy system call.
2) A task cannot at present establish what cpuset relative
mempolicy it would like to have, if it is in a smaller
cpuset than it might have mempolicy preferences for,
because the existing interface only allows specifying
mempolicies for nodes currently allowed by the cpuset.
Cpuset relative mempolicies are useful for tasks that don't distinguish
particularly between one CPU or Node and another, but only between how many of
each are allowed, and the proper placement of threads and memory pages on the
various CPUs and Nodes available.
The motivation for the added bitmap_fold() can be seen in the following
example.
Let's say an application has specified some mempolicies that presume 16 memory
nodes, including say a mempolicy that specified MPOL_F_RELATIVE_NODES (cpuset
relative) nodes 12-15. Then lets say that application is crammed into a
cpuset that only has 8 memory nodes, 0-7. If one just uses bitmap_onto(),
this mempolicy, mapped to that cpuset, would ignore the requested relative
nodes above 7, leaving it empty of nodes. That's not good; better to fold the
higher nodes down, so that some nodes are included in the resulting mapped
mempolicy. In this case, the mempolicy nodes 12-15 are taken modulo 8 (the
weight of the mems_allowed of the confining cpuset), resulting in a mempolicy
specifying nodes 4-7.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: <kosaki.motohiro@jp.fujitsu.com>
Cc: <ray-lk@madrabbit.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-28 13:12:29 +04: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 20:27:23 +04: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 13:12:29 +04: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 4 th , 6 th , 8 th and 10 th set bits
* set in @ relmap , and the 4 th , 6 th , 8 th and 10 th 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 05:57:33 +04: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 13:12:29 +04: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 23:11:35 +03: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 13:12:29 +04:00
* 40 41 42 43 45 48 53 61 74 95
2017-03-30 23:11:35 +03: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 13:12:29 +04: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 23:11:35 +03: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 13:12:29 +04: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 23:11:35 +03: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 13:12:29 +04:00
*
2017-03-30 23:11:35 +03: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 13:12:29 +04:00
* @ orig tmp @ dst
* 0 0 40
* 1 1 41
* 9 9 95
2017-03-30 23:11:35 +03: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 13:12:29 +04: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 23:11:35 +03: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 13:12:29 +04:00
*
2017-03-30 23:11:35 +03: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 13:12:29 +04: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-13 02:02:01 +03: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 13:12:29 +04:00
{
2015-02-13 02:02:01 +03: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 13:12:29 +04: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-06 00:43:18 +03: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 13:12:29 +04:00
/* m == bitmap_pos_to_ord(relmap, n, bits) */
if ( test_bit ( m , orig ) )
set_bit ( n , dst ) ;
m + + ;
}
}
/**
* bitmap_fold - fold larger bitmap into smaller , modulo specified size
* @ dst : resulting smaller bitmap
* @ orig : original larger bitmap
* @ sz : specified size
2015-02-13 02:02:04 +03: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 13:12:29 +04: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-13 02:02:04 +03: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 13:12:29 +04:00
{
2015-02-13 02:02:04 +03: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 13:12:29 +04:00
if ( dst = = orig ) /* following doesn't handle inplace mappings */
return ;
2015-02-13 02:02:04 +03: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 13:12:29 +04:00
2015-02-13 02:02:04 +03: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 13:12:29 +04:00
set_bit ( oldbit % sz , dst ) ;
}
2019-05-15 01:42:43 +03:00
# endif /* CONFIG_NUMA */
mempolicy: add bitmap_onto() and bitmap_fold() operations
The following adds two more bitmap operators, bitmap_onto() and bitmap_fold(),
with the usual cpumask and nodemask wrappers.
The bitmap_onto() operator computes one bitmap relative to another. If the
n-th bit in the origin mask is set, then the m-th bit of the destination mask
will be set, where m is the position of the n-th set bit in the relative mask.
The bitmap_fold() operator folds a bitmap into a second that has bit m set iff
the input bitmap has some bit n set, where m == n mod sz, for the specified sz
value.
There are two substantive changes between this patch and its
predecessor bitmap_relative:
1) Renamed bitmap_relative() to be bitmap_onto().
2) Added bitmap_fold().
The essential motivation for bitmap_onto() is to provide a mechanism for
converting a cpuset-relative CPU or Node mask to an absolute mask. Cpuset
relative masks are written as if the current task were in a cpuset whose CPUs
or Nodes were just the consecutive ones numbered 0..N-1, for some N. The
bitmap_onto() operator is provided in anticipation of adding support for the
first such cpuset relative mask, by the mbind() and set_mempolicy() system
calls, using a planned flag of MPOL_F_RELATIVE_NODES. These bitmap operators
(and their nodemask wrappers, in particular) will be used in code that
converts the user specified cpuset relative memory policy to a specific system
node numbered policy, given the current mems_allowed of the tasks cpuset.
Such cpuset relative mempolicies will address two deficiencies
of the existing interface between cpusets and mempolicies:
1) A task cannot at present reliably establish a cpuset
relative mempolicy because there is an essential race
condition, in that the tasks cpuset may be changed in
between the time the task can query its cpuset placement,
and the time the task can issue the applicable mbind or
set_memplicy system call.
2) A task cannot at present establish what cpuset relative
mempolicy it would like to have, if it is in a smaller
cpuset than it might have mempolicy preferences for,
because the existing interface only allows specifying
mempolicies for nodes currently allowed by the cpuset.
Cpuset relative mempolicies are useful for tasks that don't distinguish
particularly between one CPU or Node and another, but only between how many of
each are allowed, and the proper placement of threads and memory pages on the
various CPUs and Nodes available.
The motivation for the added bitmap_fold() can be seen in the following
example.
Let's say an application has specified some mempolicies that presume 16 memory
nodes, including say a mempolicy that specified MPOL_F_RELATIVE_NODES (cpuset
relative) nodes 12-15. Then lets say that application is crammed into a
cpuset that only has 8 memory nodes, 0-7. If one just uses bitmap_onto(),
this mempolicy, mapped to that cpuset, would ignore the requested relative
nodes above 7, leaving it empty of nodes. That's not good; better to fold the
higher nodes down, so that some nodes are included in the resulting mapped
mempolicy. In this case, the mempolicy nodes 12-15 are taken modulo 8 (the
weight of the mems_allowed of the confining cpuset), resulting in a mempolicy
specifying nodes 4-7.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: <kosaki.motohiro@jp.fujitsu.com>
Cc: <ray-lk@madrabbit.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-28 13:12:29 +04:00
2006-03-24 14:15:46 +03: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-17 02:20:36 +04:00
*
2006-03-24 14:15:46 +03: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-17 02:20:36 +04:00
*
2006-03-24 14:15:46 +03: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-17 02:20:36 +04:00
*/
2006-03-24 14:15:46 +03: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-07 03:10:16 +04:00
static int __reg_op ( unsigned long * bitmap , unsigned int pos , int order , int reg_op )
2005-04-17 02:20:36 +04:00
{
2006-03-24 14:15:46 +03: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 14:15:45 +03:00
int nbitsinlong ; /* num bits of region in each spanned long */
2006-03-24 14:15:46 +03:00
unsigned long mask ; /* bitmask for one long of region */
2006-03-24 14:15:45 +03:00
int i ; /* scans bitmap by longs */
2006-03-24 14:15:46 +03:00
int ret = 0 ; /* return value */
2006-03-24 14:15:45 +03:00
2006-03-24 14:15:46 +03: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-17 02:20:36 +04:00
2006-03-24 14:15:46 +03:00
/*
* Can ' t do " mask = (1UL << nbitsinlong) - 1 " , as that
* overflows if nbitsinlong = = BITS_PER_LONG .
*/
2006-03-24 14:15:45 +03:00
mask = ( 1UL < < ( nbitsinlong - 1 ) ) ;
2005-04-17 02:20:36 +04:00
mask + = mask - 1 ;
2006-03-24 14:15:46 +03:00
mask < < = offset ;
2005-04-17 02:20:36 +04:00
2006-03-24 14:15:46 +03: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-17 02:20:36 +04:00
}
2006-03-24 14:15:46 +03: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-07 03:10:16 +04:00
int bitmap_find_free_region ( unsigned long * bitmap , unsigned int bits , int order )
2006-03-24 14:15:46 +03:00
{
2014-08-07 03:10:16 +04:00
unsigned int pos , end ; /* scans bitmap by regions of size order */
2009-03-13 05:32:51 +03:00
2014-08-07 03:10:16 +04:00
for ( pos = 0 ; ( end = pos + ( 1U < < order ) ) < = bits ; pos = end ) {
2009-03-13 05:32:51 +03: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-17 02:20:36 +04:00
}
EXPORT_SYMBOL ( bitmap_find_free_region ) ;
/**
2006-03-24 14:15:44 +03:00
* bitmap_release_region - release allocated bitmap region
2006-03-24 14:15:46 +03: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-17 02:20:36 +04:00
*
2007-02-10 12:45:59 +03:00
* This is the complement to __bitmap_find_free_region ( ) and releases
2005-04-17 02:20:36 +04:00
* the found region ( by clearing it in the bitmap ) .
2006-03-24 14:15:46 +03:00
*
* No return value .
2005-04-17 02:20:36 +04:00
*/
2014-08-07 03:10:16 +04:00
void bitmap_release_region ( unsigned long * bitmap , unsigned int pos , int order )
2005-04-17 02:20:36 +04:00
{
2006-03-24 14:15:46 +03:00
__reg_op ( bitmap , pos , order , REG_OP_RELEASE ) ;
2005-04-17 02:20:36 +04:00
}
EXPORT_SYMBOL ( bitmap_release_region ) ;
2006-03-24 14:15:44 +03:00
/**
* bitmap_allocate_region - allocate bitmap region
2006-03-24 14:15:46 +03: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 14:15:44 +03:00
*
* Allocate ( set bits in ) a specified region of a bitmap .
2006-03-24 14:15:46 +03:00
*
2006-06-25 16:48:57 +04:00
* Return 0 on success , or % - EBUSY if specified region wasn ' t
2006-03-24 14:15:44 +03:00
* free ( not all bits were zero ) .
*/
2014-08-07 03:10:16 +04:00
int bitmap_allocate_region ( unsigned long * bitmap , unsigned int pos , int order )
2005-04-17 02:20:36 +04:00
{
2006-03-24 14:15:46 +03:00
if ( ! __reg_op ( bitmap , pos , order , REG_OP_ISFREE ) )
return - EBUSY ;
2014-08-07 03:10:18 +04:00
return __reg_op ( bitmap , pos , order , REG_OP_ALLOC ) ;
2005-04-17 02:20:36 +04:00
}
EXPORT_SYMBOL ( bitmap_allocate_region ) ;
2008-09-17 19:34:03 +04: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-14 01:36:00 +03:00
# ifdef __BIG_ENDIAN
2015-02-14 01:35:57 +03:00
void bitmap_copy_le ( unsigned long * dst , const unsigned long * src , unsigned int nbits )
2008-09-17 19:34:03 +04:00
{
2015-02-14 01:35:57 +03:00
unsigned int i ;
2008-09-17 19:34:03 +04:00
for ( i = 0 ; i < nbits / BITS_PER_LONG ; i + + ) {
if ( BITS_PER_LONG = = 64 )
2015-02-14 01:35:57 +03:00
dst [ i ] = cpu_to_le64 ( src [ i ] ) ;
2008-09-17 19:34:03 +04:00
else
2015-02-14 01:35:57 +03:00
dst [ i ] = cpu_to_le32 ( src [ i ] ) ;
2008-09-17 19:34:03 +04:00
}
}
EXPORT_SYMBOL ( bitmap_copy_le ) ;
2015-02-14 01:36:00 +03: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-07 02:38:02 +03:00
2018-08-02 01:42:56 +03:00
unsigned long * bitmap_alloc ( unsigned int nbits , gfp_t flags )
{
return kmalloc_array ( BITS_TO_LONGS ( nbits ) , sizeof ( unsigned long ) ,
flags ) ;
}
EXPORT_SYMBOL ( bitmap_alloc ) ;
unsigned long * bitmap_zalloc ( unsigned int nbits , gfp_t flags )
{
return bitmap_alloc ( nbits , flags | __GFP_ZERO ) ;
}
EXPORT_SYMBOL ( bitmap_zalloc ) ;
2020-12-30 12:41:52 +03:00
unsigned long * bitmap_alloc_node ( unsigned int nbits , gfp_t flags , int node )
{
return kmalloc_array_node ( BITS_TO_LONGS ( nbits ) , sizeof ( unsigned long ) ,
flags , node ) ;
}
EXPORT_SYMBOL ( bitmap_alloc_node ) ;
unsigned long * bitmap_zalloc_node ( unsigned int nbits , gfp_t flags , int node )
{
return bitmap_alloc_node ( nbits , flags | __GFP_ZERO , node ) ;
}
EXPORT_SYMBOL ( bitmap_zalloc_node ) ;
2018-08-02 01:42:56 +03:00
void bitmap_free ( const unsigned long * bitmap )
{
kfree ( bitmap ) ;
}
EXPORT_SYMBOL ( bitmap_free ) ;
2021-03-15 12:13:56 +03:00
static void devm_bitmap_free ( void * data )
{
unsigned long * bitmap = data ;
bitmap_free ( bitmap ) ;
}
unsigned long * devm_bitmap_alloc ( struct device * dev ,
unsigned int nbits , gfp_t flags )
{
unsigned long * bitmap ;
int ret ;
bitmap = bitmap_alloc ( nbits , flags ) ;
if ( ! bitmap )
return NULL ;
ret = devm_add_action_or_reset ( dev , devm_bitmap_free , bitmap ) ;
if ( ret )
return NULL ;
return bitmap ;
}
EXPORT_SYMBOL_GPL ( devm_bitmap_alloc ) ;
unsigned long * devm_bitmap_zalloc ( struct device * dev ,
unsigned int nbits , gfp_t flags )
{
return devm_bitmap_alloc ( dev , nbits , flags | __GFP_ZERO ) ;
}
EXPORT_SYMBOL_GPL ( devm_bitmap_zalloc ) ;
bitmap: new bitmap_copy_safe and bitmap_{from,to}_arr32
This patchset replaces bitmap_{to,from}_u32array with more simple and
standard looking copy-like functions.
bitmap_from_u32array() takes 4 arguments (bitmap_to_u32array is similar):
- unsigned long *bitmap, which is destination;
- unsigned int nbits, the length of destination bitmap, in bits;
- const u32 *buf, the source; and
- unsigned int nwords, the length of source buffer in ints.
In description to the function it is detailed like:
* copy min(nbits, 32*nwords) bits from @buf to @bitmap, remaining
* bits between nword and nbits in @bitmap (if any) are cleared.
Having two size arguments looks unneeded and potentially dangerous.
It is unneeded because normally user of copy-like function should take
care of the size of destination and make it big enough to fit source
data.
And it is dangerous because function may hide possible error if user
doesn't provide big enough bitmap, and data becomes silently dropped.
That's why all copy-like functions have 1 argument for size of copying
data, and I don't see any reason to make bitmap_from_u32array()
different.
One exception that comes in mind is strncpy() which also provides size
of destination in arguments, but it's strongly argued by the possibility
of taking broken strings in source. This is not the case of
bitmap_{from,to}_u32array().
There is no many real users of bitmap_{from,to}_u32array(), and they all
very clearly provide size of destination matched with the size of
source, so additional functionality is not used in fact. Like this:
bitmap_from_u32array(to->link_modes.supported,
__ETHTOOL_LINK_MODE_MASK_NBITS,
link_usettings.link_modes.supported,
__ETHTOOL_LINK_MODE_MASK_NU32);
Where:
#define __ETHTOOL_LINK_MODE_MASK_NU32 \
DIV_ROUND_UP(__ETHTOOL_LINK_MODE_MASK_NBITS, 32)
In this patch, bitmap_copy_safe and bitmap_{from,to}_arr32 are introduced.
'Safe' in bitmap_copy_safe() stands for clearing unused bits in bitmap
beyond last bit till the end of last word. It is useful for hardening
API when bitmap is assumed to be exposed to userspace.
bitmap_{from,to}_arr32 functions are replacements for
bitmap_{from,to}_u32array. They don't take unneeded nwords argument, and
so simpler in implementation and understanding.
This patch suggests optimization for 32-bit systems - aliasing
bitmap_{from,to}_arr32 to bitmap_copy_safe.
Other possible optimization is aliasing 64-bit LE bitmap_{from,to}_arr32 to
more generic function(s). But I didn't end up with the function that would
be helpful by itself, and can be used to alias 64-bit LE
bitmap_{from,to}_arr32, like bitmap_copy_safe() does. So I preferred to
leave things as is.
The following patch switches kernel to new API and introduces test for it.
Discussion is here: https://lkml.org/lkml/2017/11/15/592
[ynorov@caviumnetworks.com: rename bitmap_copy_safe to bitmap_copy_clear_tail]
Link: http://lkml.kernel.org/r/20180201172508.5739-3-ynorov@caviumnetworks.com
Link: http://lkml.kernel.org/r/20171228150019.27953-1-ynorov@caviumnetworks.com
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: David Decotigny <decot@googlers.com>,
Cc: David S. Miller <davem@davemloft.net>,
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-02-07 02:38:02 +03: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 07:56:59 +03: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-07 02:38:02 +03:00
{
unsigned int i , halfwords ;
halfwords = DIV_ROUND_UP ( nbits , 32 ) ;
for ( i = 0 ; i < halfwords ; i + + ) {
bitmap [ i / 2 ] = ( unsigned long ) buf [ i ] ;
if ( + + i < halfwords )
bitmap [ i / 2 ] | = ( ( unsigned long ) buf [ i ] ) < < 32 ;
}
/* Clear tail bits in last word beyond nbits. */
if ( nbits % BITS_PER_LONG )
bitmap [ ( halfwords - 1 ) / 2 ] & = BITMAP_LAST_WORD_MASK ( nbits ) ;
}
EXPORT_SYMBOL ( bitmap_from_arr32 ) ;
/**
* bitmap_to_arr32 - copy the contents of bitmap to a u32 array of bits
* @ buf : array of u32 ( in host byte order ) , the dest bitmap
* @ bitmap : array of unsigned longs , the source bitmap
* @ nbits : number of bits in @ bitmap
*/
void bitmap_to_arr32 ( u32 * buf , const unsigned long * bitmap , unsigned int nbits )
{
unsigned int i , halfwords ;
halfwords = DIV_ROUND_UP ( nbits , 32 ) ;
for ( i = 0 ; i < halfwords ; i + + ) {
buf [ i ] = ( u32 ) ( bitmap [ i / 2 ] & UINT_MAX ) ;
if ( + + i < halfwords )
buf [ i ] = ( u32 ) ( bitmap [ i / 2 ] > > 32 ) ;
}
/* Clear tail bits in last element of array beyond nbits. */
if ( nbits % BITS_PER_LONG )
buf [ halfwords - 1 ] & = ( u32 ) ( UINT_MAX > > ( ( - nbits ) & 31 ) ) ;
}
EXPORT_SYMBOL ( bitmap_to_arr32 ) ;
2022-04-28 23:51:13 +03:00
# endif
# if (BITS_PER_LONG == 32) && defined(__BIG_ENDIAN)
/**
* bitmap_from_arr64 - copy the contents of u64 array of bits to bitmap
* @ bitmap : array of unsigned longs , the destination bitmap
* @ buf : array of u64 ( in host byte order ) , the source bitmap
* @ nbits : number of bits in @ bitmap
*/
void bitmap_from_arr64 ( unsigned long * bitmap , const u64 * buf , unsigned int nbits )
{
int n ;
for ( n = nbits ; n > 0 ; n - = 64 ) {
u64 val = * buf + + ;
* bitmap + + = val ;
if ( n > 32 )
* bitmap + + = val > > 32 ;
}
/*
* Clear tail bits in the last word beyond nbits .
*
* Negative index is OK because here we point to the word next
* to the last word of the bitmap , except for nbits = = 0 , which
* is tested implicitly .
*/
if ( nbits % BITS_PER_LONG )
bitmap [ - 1 ] & = BITMAP_LAST_WORD_MASK ( nbits ) ;
}
EXPORT_SYMBOL ( bitmap_from_arr64 ) ;
/**
* bitmap_to_arr64 - copy the contents of bitmap to a u64 array of bits
* @ buf : array of u64 ( in host byte order ) , the dest bitmap
* @ bitmap : array of unsigned longs , the source bitmap
* @ nbits : number of bits in @ bitmap
*/
void bitmap_to_arr64 ( u64 * buf , const unsigned long * bitmap , unsigned int nbits )
{
const unsigned long * end = bitmap + BITS_TO_LONGS ( nbits ) ;
bitmap: new bitmap_copy_safe and bitmap_{from,to}_arr32
This patchset replaces bitmap_{to,from}_u32array with more simple and
standard looking copy-like functions.
bitmap_from_u32array() takes 4 arguments (bitmap_to_u32array is similar):
- unsigned long *bitmap, which is destination;
- unsigned int nbits, the length of destination bitmap, in bits;
- const u32 *buf, the source; and
- unsigned int nwords, the length of source buffer in ints.
In description to the function it is detailed like:
* copy min(nbits, 32*nwords) bits from @buf to @bitmap, remaining
* bits between nword and nbits in @bitmap (if any) are cleared.
Having two size arguments looks unneeded and potentially dangerous.
It is unneeded because normally user of copy-like function should take
care of the size of destination and make it big enough to fit source
data.
And it is dangerous because function may hide possible error if user
doesn't provide big enough bitmap, and data becomes silently dropped.
That's why all copy-like functions have 1 argument for size of copying
data, and I don't see any reason to make bitmap_from_u32array()
different.
One exception that comes in mind is strncpy() which also provides size
of destination in arguments, but it's strongly argued by the possibility
of taking broken strings in source. This is not the case of
bitmap_{from,to}_u32array().
There is no many real users of bitmap_{from,to}_u32array(), and they all
very clearly provide size of destination matched with the size of
source, so additional functionality is not used in fact. Like this:
bitmap_from_u32array(to->link_modes.supported,
__ETHTOOL_LINK_MODE_MASK_NBITS,
link_usettings.link_modes.supported,
__ETHTOOL_LINK_MODE_MASK_NU32);
Where:
#define __ETHTOOL_LINK_MODE_MASK_NU32 \
DIV_ROUND_UP(__ETHTOOL_LINK_MODE_MASK_NBITS, 32)
In this patch, bitmap_copy_safe and bitmap_{from,to}_arr32 are introduced.
'Safe' in bitmap_copy_safe() stands for clearing unused bits in bitmap
beyond last bit till the end of last word. It is useful for hardening
API when bitmap is assumed to be exposed to userspace.
bitmap_{from,to}_arr32 functions are replacements for
bitmap_{from,to}_u32array. They don't take unneeded nwords argument, and
so simpler in implementation and understanding.
This patch suggests optimization for 32-bit systems - aliasing
bitmap_{from,to}_arr32 to bitmap_copy_safe.
Other possible optimization is aliasing 64-bit LE bitmap_{from,to}_arr32 to
more generic function(s). But I didn't end up with the function that would
be helpful by itself, and can be used to alias 64-bit LE
bitmap_{from,to}_arr32, like bitmap_copy_safe() does. So I preferred to
leave things as is.
The following patch switches kernel to new API and introduces test for it.
Discussion is here: https://lkml.org/lkml/2017/11/15/592
[ynorov@caviumnetworks.com: rename bitmap_copy_safe to bitmap_copy_clear_tail]
Link: http://lkml.kernel.org/r/20180201172508.5739-3-ynorov@caviumnetworks.com
Link: http://lkml.kernel.org/r/20171228150019.27953-1-ynorov@caviumnetworks.com
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: David Decotigny <decot@googlers.com>,
Cc: David S. Miller <davem@davemloft.net>,
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-02-07 02:38:02 +03:00
2022-04-28 23:51:13 +03:00
while ( bitmap < end ) {
* buf = * bitmap + + ;
if ( bitmap < end )
* buf | = ( u64 ) ( * bitmap + + ) < < 32 ;
buf + + ;
}
/* Clear tail bits in the last element of array beyond nbits. */
if ( nbits % 64 )
2022-07-11 21:09:29 +03:00
buf [ - 1 ] & = GENMASK_ULL ( ( nbits - 1 ) % 64 , 0 ) ;
2022-04-28 23:51:13 +03:00
}
EXPORT_SYMBOL ( bitmap_to_arr64 ) ;
bitmap: new bitmap_copy_safe and bitmap_{from,to}_arr32
This patchset replaces bitmap_{to,from}_u32array with more simple and
standard looking copy-like functions.
bitmap_from_u32array() takes 4 arguments (bitmap_to_u32array is similar):
- unsigned long *bitmap, which is destination;
- unsigned int nbits, the length of destination bitmap, in bits;
- const u32 *buf, the source; and
- unsigned int nwords, the length of source buffer in ints.
In description to the function it is detailed like:
* copy min(nbits, 32*nwords) bits from @buf to @bitmap, remaining
* bits between nword and nbits in @bitmap (if any) are cleared.
Having two size arguments looks unneeded and potentially dangerous.
It is unneeded because normally user of copy-like function should take
care of the size of destination and make it big enough to fit source
data.
And it is dangerous because function may hide possible error if user
doesn't provide big enough bitmap, and data becomes silently dropped.
That's why all copy-like functions have 1 argument for size of copying
data, and I don't see any reason to make bitmap_from_u32array()
different.
One exception that comes in mind is strncpy() which also provides size
of destination in arguments, but it's strongly argued by the possibility
of taking broken strings in source. This is not the case of
bitmap_{from,to}_u32array().
There is no many real users of bitmap_{from,to}_u32array(), and they all
very clearly provide size of destination matched with the size of
source, so additional functionality is not used in fact. Like this:
bitmap_from_u32array(to->link_modes.supported,
__ETHTOOL_LINK_MODE_MASK_NBITS,
link_usettings.link_modes.supported,
__ETHTOOL_LINK_MODE_MASK_NU32);
Where:
#define __ETHTOOL_LINK_MODE_MASK_NU32 \
DIV_ROUND_UP(__ETHTOOL_LINK_MODE_MASK_NBITS, 32)
In this patch, bitmap_copy_safe and bitmap_{from,to}_arr32 are introduced.
'Safe' in bitmap_copy_safe() stands for clearing unused bits in bitmap
beyond last bit till the end of last word. It is useful for hardening
API when bitmap is assumed to be exposed to userspace.
bitmap_{from,to}_arr32 functions are replacements for
bitmap_{from,to}_u32array. They don't take unneeded nwords argument, and
so simpler in implementation and understanding.
This patch suggests optimization for 32-bit systems - aliasing
bitmap_{from,to}_arr32 to bitmap_copy_safe.
Other possible optimization is aliasing 64-bit LE bitmap_{from,to}_arr32 to
more generic function(s). But I didn't end up with the function that would
be helpful by itself, and can be used to alias 64-bit LE
bitmap_{from,to}_arr32, like bitmap_copy_safe() does. So I preferred to
leave things as is.
The following patch switches kernel to new API and introduces test for it.
Discussion is here: https://lkml.org/lkml/2017/11/15/592
[ynorov@caviumnetworks.com: rename bitmap_copy_safe to bitmap_copy_clear_tail]
Link: http://lkml.kernel.org/r/20180201172508.5739-3-ynorov@caviumnetworks.com
Link: http://lkml.kernel.org/r/20171228150019.27953-1-ynorov@caviumnetworks.com
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: David Decotigny <decot@googlers.com>,
Cc: David S. Miller <davem@davemloft.net>,
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-02-07 02:38:02 +03:00
# endif