summaryrefslogtreecommitdiff
path: root/include/linux/bitmap.h
AgeCommit message (Collapse)Author
2007-10-19remove BITS_TO_TYPE macroJiri Slaby
remove BITS_TO_TYPE macro I realized, that it is actually the same as DIV_ROUND_UP, use it instead. [akpm@linux-foundation.org: build fix] Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2006-10-11[PATCH] bitmap: parse input from kernel and user buffersReinette Chatre
lib/bitmap.c:bitmap_parse() is a library function that received as input a user buffer. This seemed to have originated from the way the write_proc function of the /proc filesystem operates. This has been reworked to not use kmalloc and eliminates a lot of get_user() overhead by performing one access_ok before using __get_user(). We need to test if we are in kernel or user space (is_user) and access the buffer differently. We cannot use __get_user() to access kernel addresses in all cases, for example in architectures with separate address space for kernel and user. This function will be useful for other uses as well; for example, taking input for /sysfs instead of /proc, so it was changed to accept kernel buffers. We have this use for the Linux UWB project, as part as the upcoming bandwidth allocator code. Only a few routines used this function and they were changed too. Signed-off-by: Reinette Chatre <reinette.chatre@linux.intel.com> Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Cc: Paul Jackson <pj@sgi.com> Cc: Joe Korty <joe.korty@ccur.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: Optimize bitmap_weight for small bitmapsAndi Kleen
Use inline code bitmaps <= BITS_PER_LONG in bitmap_weight. This gives _much_ better code. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-24[PATCH] bitmap: region cleanupPaul Jackson
Paul Mundt <lethal@linux-sh.org> says: This patch set implements a number of patches to clean up and restructure the bitmap region code, in addition to extending the interface to support multiword spanning allocations. The current implementation (before this patch set) is limited by only being able to allocate pages <= BITS_PER_LONG, as noted by the strategically positioned BUG_ON() at lib/bitmap.c:752: /* We don't do regions of pages > BITS_PER_LONG. The * algorithm would be a simple look for multiple zeros in the * array, but there's no driver today that needs this. If you * trip this BUG(), you get to code it... */ BUG_ON(pages > BITS_PER_LONG); As I seem to have been the first person to trigger this, the result ends up being the following patch set with the help of Paul Jackson. The final patch in the series eliminates quite a bit of code duplication, so the bitmap code size ends up being smaller than the current implementation as an added bonus. After these are applied, it should already be possible to do multiword allocations with dma_alloc_coherent() out of ranges established by dma_declare_coherent_memory() on x86 without having to change any of the code, and the SH store queue API will follow up on this as the other user that needs support for this. This patch: Some code cleanup on the lib/bitmap.c bitmap_*_region() routines: * spacing * variable names * comments Has no change to code function. Signed-off-by: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Paul Jackson <pj@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] cpusets: bitmap and mask remap operatorsPaul Jackson
In the forthcoming task migration support, a key calculation will be mapping cpu and node numbers from the old set to the new set while preserving cpuset-relative offset. For example, if a task and its pages on nodes 8-11 are being migrated to nodes 24-27, then pages on node 9 (the 2nd node in the old set) should be moved to node 25 (the 2nd node in the new set.) As with other bitmap operations, the proper way to code this is to provide the underlying calculation in lib/bitmap.c, and then to provide the usual cpumask and nodemask wrappers. This patch provides that. These operations are termed 'remap' operations. Both remapping a single bit and a set of bits is supported. Signed-off-by: Paul Jackson <pj@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-03-09[PATCH] new bitmap list format (for cpusets)Paul Jackson
[This is a copy of the bitmap list format patch that I submitted to lkml on 9 Aug 2004, after removing the prefix character fluff^Wstuff. I include it here again just to get it associated with the current cpuset patch, which will follow in a second email 10 seconds later. -pj] A bitmap print and parse format that provides lists of ranges of numbers, to be first used for by cpusets (next patch). Cpusets provide a way to manage subsets of CPUs and Memory Nodes for scheduling and memory placement, via a new virtual file system, usually mounted at /dev/cpuset. Manipulation of cpusets can be done directly via this file system, from the shell. However, manipulating 512 bit cpumasks or 256 bit nodemasks (which will get bigger) via hex mask strings is painful for humans. The intention is to provide a format for the cpu and memory mask files in /dev/cpusets that will stand the test of time. This format is supported by a couple of new lib/bitmap.c routines, for printing and parsing these strings. Wrappers for cpumask and nodemask are provided. Signed-off-by: Paul Jackson <pj@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2004-06-30Add memory region bitmap implementationsJames Bottomley
These APIs deal with bitmaps representing contiguous memory regions. The idea is to set, free and find a contiguous area. For ease of implementation (as well as to conform to the standard requirements), the bitmaps always return n aligned n length regions. The implementation is also limited to BITS_PER_LONG contiguous regions. Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2004-06-23[PATCH] cpumask: bitmap inlining and optimizationsAndrew Morton
From: Paul Jackson <pj@sgi.com> These bitmap improvements make it a suitable basis for fully supporting cpumask_t and nodemask_t. Inline macros with compile-time checks enable generating tight code on both small and large systems (large meaning cpumask_t requires more than one unsigned long's worth of bits). The existing bitmap_<op> macros in lib/bitmap.c are renamed to __bitmap_<op>, and wrappers for each bitmap_<op> are exposed in include/linux/bitmap.h This patch _includes_ Bill Irwins rewrite of the bitmap_shift operators to not require a fixed length intermediate bitmap. Improved comments list each available operator for easy browsing. Signed-off-by: Paul Jackson <pj@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2004-06-23[PATCH] cpumask: bitmap cleanup preparation for cpumask overhaulAndrew Morton
From: Paul Jackson <pj@sgi.com> Document the bitmap bit model and handling of unused bits. Tighten up bitmap so it does not generate nonzero bits in the unused tail if it is not given any on input. Add intersects, subset, xor and andnot operators. Change bitmap_complement to take two operands. Add a couple of missing 'const' qualifiers on bitops test_bit and bitmap_equal args. Signed-off-by: Paul Jackson <pj@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2004-05-22[PATCH] numa api: x86_64 supportAndrew Morton
From: Andi Kleen <ak@suse.de> Add NUMA API system calls on x86-64 This includes a bugfix to prevent miscompilation on gcc 3.2 of bitmap.h
2004-04-12[PATCH] Rename bitmap_clear to bitmap_zero, remove CLEAR_BITMAPAndrew Morton
From: Rusty Russell <rusty@rustcorp.com.au> clear_bit(n, addr) clears the nth bit. test_and_clear_bit(n, addr) clears the nth bit. cpu_clear(n, cpumask) clears the nth bit (vs. cpus_clear()). bitmap_clear(bitmap, n) clears out all the bits up to n. Moreover, there's a CLEAR_BITMAP() in linux/types.h which bitmap_clear() is a wrapper for. Rename bitmap_clear to bitmap_zero, which is harder to confuse (yes, it bit me), and make everyone use it.
2004-02-18[PATCH] Rename bitmap_snprintf() and cpumask_snprintf() to *_scnprintf()Andrew Morton
From: Joe Korty <joe.korty@ccur.com> Rename bitmap_snprintf() to bitmap_scnprintf() and cpumask_snprintf() to cpumask_scnprintf(), as these functions now belong to the scnprintf family of functions.
2004-02-03[PATCH] bitmap parsing/printing routines, version 4Andrew Morton
From: Joe Korty <joe.korty@ccur.com> 1) the version in 2.6.1 is broken, doesn't work on 64bit big endian machines at all. This needed fixing. I thought it best to fix by rewriting the printer/parser with an algorithm that is naturally endian & sizeof(long) resistant. 2) I wanted all digits to print, eg, 0000ffff,00000004 not ffff,4. 3) I wanted exactly NR_CPUS bits to print (or whatever the bitmap size is in bits, and not have what is displayed rounded up to the nearest full byte, as the current version did. 4) The bitmap printer and parser should be part of bitmap.[ch] with syntax and semantics to match. The original lib/mask.c versions did not recognize this commonality.
2004-01-19[PATCH] uninline bitmap functionsAndrew Morton
- A couple of them are using alloca (via DECLARE_BITMAP) and this generates a cannot-inline warning with -Winline. - These functions are too big to inline anwyay.
2003-08-18[PATCH] cpumask_t: allow more than BITS_PER_LONG CPUsAndrew Morton
From: William Lee Irwin III <wli@holomorphy.com> Contributions from: Jan Dittmer <jdittmer@sfhq.hn.org> Arnd Bergmann <arnd@arndb.de> "Bryan O'Sullivan" <bos@serpentine.com> "David S. Miller" <davem@redhat.com> Badari Pulavarty <pbadari@us.ibm.com> "Martin J. Bligh" <mbligh@aracnet.com> Zwane Mwaikambo <zwane@linuxpower.ca> It has ben tested on x86, sparc64, x86_64, ia64 (I think), ppc and ppc64. cpumask_t enables systems with NR_CPUS > BITS_PER_LONG to utilize all their cpus by creating an abstract data type dedicated to representing cpu bitmasks, similar to fd sets from userspace, and sweeping the appropriate code to update callers to the access API. The fd set-like structure is according to Linus' own suggestion; the macro calling convention to ambiguate representations with minimal code impact is my own invention. Specifically, a new set of inline functions for manipulating arbitrary-width bitmaps is introduced with a relatively simple implementation, in tandem with a new data type representing bitmaps of width NR_CPUS, cpumask_t, whose accessor functions are defined in terms of the bitmap manipulation inlines. This bitmap ADT found an additional use in i386 arch code handling sparse physical APIC ID's, which was convenient to use in this case as the accounting structure was required to be wider to accommodate the physids consumed by larger numbers of cpus. For the sake of simplicity and low code impact, these cpu bitmasks are passed primarily by value; however, an additional set of accessors along with an auxiliary data type with const call-by-reference semantics is provided to address performance concerns raised in connection with very large systems, such as SGI's larger models, where copying and call-by-value overhead would be prohibitive. Few (if any) users of the call-by-reference API are immediately introduced. Also, in order to avoid calling convention overhead on architectures where structures are required to be passed by value, NR_CPUS <= BITS_PER_LONG is special-cased so that cpumask_t falls back to an unsigned long and the accessors perform the usual bit twiddling on unsigned longs as opposed to arrays thereof. Audits were done with the structure overhead in-place, restoring this special-casing only afterward so as to ensure a more complete API conversion while undergoing the majority of its end-user exposure in -mm. More -mm's were shipped after its restoration to be sure that was tested, too. The immediate users of this functionality are Sun sparc64 systems, SGI mips64 and ia64 systems, and IBM ia32, ppc64, and s390 systems. Of these, only the ppc64 machines needing the functionality have yet to be released; all others have had systems requiring it for full functionality for at least 6 months, and in some cases, since the initial Linux port to the affected architecture.