summaryrefslogtreecommitdiff
path: root/include/linux/bitmap.h
AgeCommit message (Collapse)Author
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.