31 May, 2010

1 commit

  • This reverts commit 0ac0c0d0f837c499afd02a802f9cf52d3027fa3b, which
    caused cross-architecture build problems for all the wrong reasons.
    IA64 already added its own version of __node_random(), but the fact is,
    there is nothing architectural about the function, and the original
    commit was just badly done. Revert it, since no fix is forthcoming.

    Requested-by: Stephen Rothwell
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

28 May, 2010

1 commit

  • Some workloads that create a large number of small files tend to assign
    too many pages to node 0 (multi-node systems). Part of the reason is that
    the rotor (in cpuset_mem_spread_node()) used to assign nodes starts at
    node 0 for newly created tasks.

    This patch changes the rotor to be initialized to a random node number of
    the cpuset.

    [akpm@linux-foundation.org: fix layout]
    [Lee.Schermerhorn@hp.com: Define stub numa_random() for !NUMA configuration]
    Signed-off-by: Jack Steiner
    Signed-off-by: Lee Schermerhorn
    Cc: Christoph Lameter
    Cc: Pekka Enberg
    Cc: Paul Menage
    Cc: Jack Steiner
    Cc: Robin Holt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jack Steiner
     

07 Mar, 2010

2 commits


16 Dec, 2009

1 commit

  • This introduces new bitmap functions:

    bitmap_set: Set specified bit area
    bitmap_clear: Clear specified bit area
    bitmap_find_next_zero_area: Find free bit area

    These are mostly stolen from iommu helper. The differences are:

    - Use find_next_bit instead of doing test_bit for each bit

    - Rewrite bitmap_set and bitmap_clear

    Instead of setting or clearing for each bit.

    - Check the last bit of the limit

    iommu-helper doesn't want to find such area

    - The return value if there is no zero area

    find_next_zero_area in iommu helper: returns -1
    bitmap_find_next_zero_area: return >= bitmap size

    Signed-off-by: Akinobu Mita
    Cc: FUJITA Tomonori
    Cc: "David S. Miller"
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: "H. Peter Anvin"
    Cc: Greg Kroah-Hartman
    Cc: Lothar Wassmann
    Cc: Roland Dreier
    Cc: Yevgeny Petrilin
    Cc: Tony Luck
    Cc: Fenghua Yu
    Cc: Joerg Roedel
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Akinobu Mita
     

22 Aug, 2009

1 commit

  • When 'and'ing two bitmasks (where 'andnot' is a variation on it), some
    cases want to know whether the result is the empty set or not. In
    particular, the TLB IPI sending code wants to do cpumask operations and
    determine if there are any CPU's left in the final set.

    So this just makes the bitmask (and cpumask) functions return a boolean
    for whether the result has any bits set.

    Cc: stable@kernel.org (2.6.30, needed by TLB shootdown fix)
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

13 Mar, 2009

1 commit

  • Guennadi Liakhovetski noticed that the end condition for the loop in
    bitmap_find_free_region() is wrong, and the "return if error" was also
    using the wrong conditional that would only trigger if the bitmap was an
    exact multiple of the allocation size, which is not necessarily the case
    with dma_alloc_from_coherent().

    Such a failure would end up in bitmap_find_free_region() accessing
    beyond the end of the bitmap.

    Reported-by: Guennadi Liakhovetski
    Cc: Andrew Morton
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

23 Oct, 2008

1 commit

  • * 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/dvrabel/uwb: (47 commits)
    uwb: wrong sizeof argument in mac address compare
    uwb: don't use printk_ratelimit() so often
    uwb: use kcalloc where appropriate
    uwb: use time_after() when purging stale beacons
    uwb: add credits for the original developers of the UWB/WUSB/WLP subsystems
    uwb: add entries in the MAINTAINERS file
    uwb: depend on EXPERIMENTAL
    wusb: wusb-cbaf (CBA driver) sysfs ABI simplification
    uwb: document UWB and WUSB sysfs files
    uwb: add symlinks in sysfs between radio controllers and PALs
    uwb: dont tranmit identification IEs
    uwb: i1480/GUWA100U: fix firmware download issues
    uwb: i1480: remove MAC/PHY information checking function
    uwb: add Intel i1480 HWA to the UWB RC quirk table
    uwb: disable command/event filtering for D-Link DUB-1210
    uwb: initialize the debug sub-system
    uwb: Fix handling IEs with empty IE data in uwb_est_get_size()
    wusb: fix bmRequestType for Abort RPipe request
    wusb: fix error path for wusb_set_dev_addr()
    wusb: add HWA host controller driver
    ...

    Linus Torvalds
     

20 Oct, 2008

1 commit

  • bitmap_scnprintf_len() is not used now, so we remove it.

    Otherwise we have to maintain it and make its return
    value always equal to bitmap_scnprintf()'s return value.

    Signed-off-by: Lai Jiangshan
    Cc: Alexey Dobriyan
    Cc: Paul Menage
    Cc: Paul Jackson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Lai Jiangshan
     

17 Sep, 2008

1 commit

  • bitmap_copy_le() copies a bitmap, putting the bits into little-endian
    order (i.e., each unsigned long word in the bitmap is put into
    little-endian order).

    The UWB stack used bitmaps to manage Medium Access Slot availability,
    and these bitmaps need to be written to the hardware in LE order.

    Signed-off-by: David Vrabel

    David Vrabel
     

13 Aug, 2008

1 commit

  • Short enough reads from /proc/irq/*/smp_affinity return -EINVAL for no
    good reason.

    This became noticed with NR_CPUS=4096 patches, when length of printed
    representation of cpumask becase 1152, but cat(1) continued to read with
    1024-byte chunks. bitmap_scnprintf() in good faith fills buffer, returns
    1023, check returns -EINVAL.

    Fix it by switching to seq_file, so handler will just fill buffer and
    doesn't care about offsets, length, filling EOF and all this crap.

    For that add seq_bitmap(), and wrappers around it -- seq_cpumask() and
    seq_nodemask().

    Signed-off-by: Alexey Dobriyan
    Reviewed-by: Paul Jackson
    Cc: Mike Travis
    Cc: Al Viro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alexey Dobriyan
     

13 May, 2008

1 commit

  • They aren't used. They were briefly used as part of some other patches to
    provide an alternative format for displaying some /proc and /sys cpumasks.
    They probably should have been removed when those other patches were dropped,
    in favor of a different solution.

    Signed-off-by: Paul Jackson
    Cc: "Mike Travis"
    Cc: "Bert Wesarg"
    Cc: Alexey Dobriyan
    Cc: WANG Cong
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul Jackson
     

28 Apr, 2008

1 commit

  • 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
    Signed-off-by: David Rientjes
    Cc: Christoph Lameter
    Cc: Andi Kleen
    Cc: Mel Gorman
    Cc: Lee Schermerhorn
    Cc:
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul Jackson
     

20 Apr, 2008

1 commit

  • Add a new function cpumask_scnprintf_len() to return the number of
    characters needed to display "len" cpumask bits. The current method
    of allocating NR_CPUS bytes is incorrect as what's really needed is
    9 characters per 32-bit word of cpumask bits (8 hex digits plus the
    seperator [','] or the terminating NULL.) This function provides the
    caller the means to allocate the correct string length.

    Cc: Paul Jackson
    Signed-off-by: Mike Travis
    Signed-off-by: Ingo Molnar

    Mike Travis
     

06 Nov, 2007

1 commit

  • When a bitmap is empty bitmap_scnlistprintf() would leave the buffer
    uninitialized. Set it to an empty string in this case.

    I didn't see any in normal kernel callers hitting this, but some custom
    debug code of mine did.

    Signed-off-by: Andi Kleen
    Acked-by: Paul Jackson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andi Kleen
     

02 Mar, 2007

1 commit


12 Feb, 2007

1 commit

  • A variety of (mostly) innocuous fixes to the embedded kernel-doc content in
    source files, including:

    * make multi-line initial descriptions single line
    * denote some function names, constants and structs as such
    * change erroneous opening '/*' to '/**' in a few places
    * reword some text for clarity

    Signed-off-by: Robert P. J. Day
    Cc: "Randy.Dunlap"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Robert P. J. Day
     

12 Oct, 2006

1 commit

  • 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
    Signed-off-by: Inaky Perez-Gonzalez
    Cc: Paul Jackson
    Cc: Joe Korty
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Reinette Chatre
     

26 Jun, 2006

1 commit


27 Mar, 2006

1 commit

  • By defining generic hweight*() routines

    - hweight64() will be defined on all architectures
    - hweight_long() will use architecture optimized hweight32() or hweight64()

    I found two possible cleanups by these reasons.

    Signed-off-by: Akinobu Mita
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Akinobu Mita
     

24 Mar, 2006

3 commits

  • Restructure the bitmap_*_region() operations, to avoid code duplication.

    Also reduces binary text size by about 100 bytes (ia64 arch). The original
    Bottomley bitmap_*_region patch added about 1000 bytes of compiled kernel text
    (ia64). The Mundt multiword extension added another 600 bytes, and this
    restructuring patch gets back about 100 bytes.

    But the real motivation was the reduced amount of duplicated code.

    Tested by Paul Mundt using
    Signed-off-by: Paul Jackson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul Jackson
     
  • Add support to the lib/bitmap.c bitmap_*_region() routines

    For bitmap regions larger than one word (nbits > BITS_PER_LONG). This removes
    a BUG_ON() in lib bitmap.

    I have an updated store queue API for SH that is currently using this with
    relative success, and at first glance, it seems like this could be useful for
    x86 (arch/i386/kernel/pci-dma.c) as well. Particularly for anything using
    dma_declare_coherent_memory() on large areas and that attempts to allocate
    large buffers from that space.

    Paul Jackson also did some cleanup to this patch.

    Signed-off-by: Paul Mundt
    Signed-off-by: Paul Jackson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul Mundt
     
  • Paul Mundt 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 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
    Signed-off-by: Paul Jackson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul Jackson
     

09 Jan, 2006

1 commit

  • Fix the default behaviour for the remap operators in bitmap, cpumask and
    nodemask.

    As previously submitted, the pair of masks 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 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
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul Jackson
     

31 Oct, 2005

1 commit

  • 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
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul Jackson
     

26 Jun, 2005

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds