Eric Lee / smarc-ti-linux-kernel

14 Sep, 2014

1 commit

  • 23d0db76f   Make hash_64() use a 64-bit multiply when appropriate ... Browse Code »

    The hash_64() function historically does the multiply by the
    GOLDEN_RATIO_PRIME_64 number with explicit shifts and adds, because
    unlike the 32-bit case, gcc seems unable to turn the constant multiply
    into the more appropriate shift and adds when required.

    However, that means that we generate those shifts and adds even when the
    architecture has a fast multiplier, and could just do it better in
    hardware.

    Use the now-cleaned-up CONFIG_ARCH_HAS_FAST_MULTIPLIER (together with
    "is it a 64-bit architecture") to decide whether to use an integer
    multiply or the explicit sequence of shift/add instructions.

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

18 Dec, 2013

1 commit

  • 71ae8aac3   lib: introduce arch optimized hash library ... Browse Code »
    13

    We introduce a new hashing library that is meant to be used in
    the contexts where speed is more important than uniformity of the
    hashed values. The hash library leverages architecture specific
    implementation to achieve high performance and fall backs to
    jhash() for the generic case.

    On Intel-based x86 architectures, the library can exploit the crc32l
    instruction, part of the Intel SSE4.2 instruction set, if the
    instruction is supported by the processor. This implementation
    is twice as fast as the jhash() implementation on an i7 processor.

    Additional architectures, such as Arm64 provide instructions for
    accelerating the computation of CRC, so they could be added as well
    in follow-up work.

    Signed-off-by: Francesco Fusco
    Signed-off-by: Daniel Borkmann
    Signed-off-by: Thomas Graf
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: David S. Miller

    Francesco Fusco
     

18 Mar, 2013

1 commit

  • 65c105535   kprobes: Make hash_64() as always inlined ... Browse Code »

    Because hash_64() is called from the get_kprobe() inside
    int3 handler, kernel causes int3 recursion and crashes if
    kprobes user puts a probe on it.

    Usually hash_64() is inlined into caller function, but in
    some cases, it has instances by gcc's interprocedural
    constant propagation.

    This patch uses __always_inline instead of inline to
    prevent gcc from doing such things.

    Reported-by: Timo Juhani Lindfors
    Signed-off-by: Masami Hiramatsu
    Acked-by: Ananth N Mavinakayanahalli
    Cc: Pavel Emelyanov
    Cc: Jiri Kosina
    Cc: Nadia Yvette Chambers
    Cc: yrl.pp-manager.tt@hitachi.com
    Cc: David S. Miller
    Cc: Linus Torvalds
    Link: http://lkml.kernel.org/r/20130314115230.19690.39387.stgit@mhiramat-M0-7522
    Signed-off-by: Ingo Molnar

    Masami Hiramatsu
     

06 Dec, 2012

1 commit

10 Aug, 2012

1 commit

  • b14f243a4   net: Dont use ifindices in hash fns ... Browse Code »

    Eric noticed, that when there will be devices with equal indices, some
    hash functions that use them will become less effective as they could.
    Fix this in advance by mixing the net_device address into the hash value
    instead of the device index.

    This is true for arp and ndisc hash fns. The netlabel, can and llc ones
    are also ifindex-based, but that three are init_net-only, thus will not
    be affected.

    Many thanks to David and Eric for the hash32_ptr implementation!

    Signed-off-by: Pavel Emelyanov
    Signed-off-by: Eric Dumazet
    Signed-off-by: David S. Miller

    Pavel Emelyanov
     

18 Aug, 2011

1 commit

07 Feb, 2008

1 commit

  • 4e701482d   hash: add explicit u32 and u64 versions of hash ... Browse Code »

    The 32-bit version is more efficient (and apparently gives better hash
    results than the 64-bit version), so users who are only hashing a 32-bit
    quantity can now opt to use the 32-bit version explicitly, rather than
    promoting to a long.

    Signed-off-by: Matthew Wilcox
    Cc: William Lee Irwin III
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Matthew Wilcox
     

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »
    212

    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