14 Apr, 2016

2 commits

  • These identifiers are bogus. The interested architectures should define
    HAVE_EFFICIENT_UNALIGNED_ACCESS whenever relevant to do so. If this
    isn't true for some arch, it should be fixed in the arch definition.

    Signed-off-by: Rui Salvaterra
    Reviewed-by: Sergey Senozhatsky
    Signed-off-by: Greg Kroah-Hartman

    Rui Salvaterra
     
  • Based on Sergey's test patch [1], this fixes zram with lz4 compression
    on big endian cpus.

    Note that the 64-bit preprocessor test is not a cleanup, it's part of
    the fix, since those identifiers are bogus (for example, __ppc64__
    isn't defined anywhere else in the kernel, which means we'd fall into
    the 32-bit definitions on ppc64).

    Tested on ppc64 with no regression on x86_64.

    [1] http://marc.info/?l=linux-kernel&m=145994470805853&w=4

    Cc: stable@vger.kernel.org
    Suggested-by: Sergey Senozhatsky
    Signed-off-by: Rui Salvaterra
    Reviewed-by: Sergey Senozhatsky
    Signed-off-by: Greg Kroah-Hartman

    Rui Salvaterra
     

10 Jul, 2013

2 commits

  • This patchset is for supporting LZ4 compression and the crypto API using
    it.

    As shown below, the size of data is a little bit bigger but compressing
    speed is faster under the enabled unaligned memory access. We can use
    lz4 de/compression through crypto API as well. Also, It will be useful
    for another potential user of lz4 compression.

    lz4 Compression Benchmark:
    Compiler: ARM gcc 4.6.4
    ARMv7, 1 GHz based board
    Kernel: linux 3.4
    Uncompressed data Size: 101 MB
    Compressed Size compression Speed
    LZO 72.1MB 32.1MB/s, 33.0MB/s(UA)
    LZ4 75.1MB 30.4MB/s, 35.9MB/s(UA)
    LZ4HC 59.8MB 2.4MB/s, 2.5MB/s(UA)
    - UA: Unaligned memory Access support
    - Latest patch set for LZO applied

    This patch:

    Add support for LZ4 compression in the Linux Kernel. LZ4 Compression APIs
    for kernel are based on LZ4 implementation by Yann Collet and were changed
    for kernel coding style.

    LZ4 homepage : http://fastcompression.blogspot.com/p/lz4.html
    LZ4 source repository : http://code.google.com/p/lz4/
    svn revision : r90

    Two APIs are added:

    lz4_compress() support basic lz4 compression whereas lz4hc_compress()
    support high compression or CPU performance get lower but compression
    ratio get higher. Also, we require the pre-allocated working memory with
    the defined size and destination buffer must be allocated with the size of
    lz4_compressbound.

    [akpm@linux-foundation.org: make lz4_compresshcctx() static]
    Signed-off-by: Chanho Min
    Cc: "Darrick J. Wong"
    Cc: Bob Pearson
    Cc: Richard Weinberger
    Cc: Herbert Xu
    Cc: Yann Collet
    Cc: Kyungsik Lee
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Chanho Min
     
  • Add support for LZ4 decompression in the Linux Kernel. LZ4 Decompression
    APIs for kernel are based on LZ4 implementation by Yann Collet.

    Benchmark Results(PATCH v3)
    Compiler: Linaro ARM gcc 4.6.2

    1. ARMv7, 1.5GHz based board
    Kernel: linux 3.4
    Uncompressed Kernel Size: 14MB
    Compressed Size Decompression Speed
    LZO 6.7MB 20.1MB/s, 25.2MB/s(UA)
    LZ4 7.3MB 29.1MB/s, 45.6MB/s(UA)

    2. ARMv7, 1.7GHz based board
    Kernel: linux 3.7
    Uncompressed Kernel Size: 14MB
    Compressed Size Decompression Speed
    LZO 6.0MB 34.1MB/s, 52.2MB/s(UA)
    LZ4 6.5MB 86.7MB/s
    - UA: Unaligned memory Access support
    - Latest patch set for LZO applied

    This patch set is for adding support for LZ4-compressed Kernel. LZ4 is a
    very fast lossless compression algorithm and it also features an extremely
    fast decoder [1].

    But we have five of decompressors already and one question which does
    arise, however, is that of where do we stop adding new ones? This issue
    had been discussed and came to the conclusion [2].

    Russell King said that we should have:

    - one decompressor which is the fastest
    - one decompressor for the highest compression ratio
    - one popular decompressor (eg conventional gzip)

    If we have a replacement one for one of these, then it should do exactly
    that: replace it.

    The benchmark shows that an 8% increase in image size vs a 66% increase
    in decompression speed compared to LZO(which has been known as the
    fastest decompressor in the Kernel). Therefore the "fast but may not be
    small" compression title has clearly been taken by LZ4 [3].

    [1] http://code.google.com/p/lz4/
    [2] http://thread.gmane.org/gmane.linux.kbuild.devel/9157
    [3] http://thread.gmane.org/gmane.linux.kbuild.devel/9347

    LZ4 homepage: http://fastcompression.blogspot.com/p/lz4.html
    LZ4 source repository: http://code.google.com/p/lz4/

    Signed-off-by: Kyungsik Lee
    Signed-off-by: Yann Collet
    Cc: "H. Peter Anvin"
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: Russell King
    Cc: Borislav Petkov
    Cc: Florian Fainelli
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kyungsik Lee