Eric Lee / smarc-fsl-linux-kernel

01 Feb, 2020

2 commits

  • 803521b14   lib/zlib: add zlib_deflate_dfltcc_enabled() function ... Browse Code »

    Add a new function to zlib.h checking if s390 Deflate-Conversion
    facility is installed and enabled.

    Link: http://lkml.kernel.org/r/20200103223334.20669-6-zaslonko@linux.ibm.com
    Signed-off-by: Mikhail Zaslonko
    Cc: Chris Mason
    Cc: Christian Borntraeger
    Cc: David Sterba
    Cc: Eduard Shishkin
    Cc: Heiko Carstens
    Cc: Ilya Leoshkevich
    Cc: Josef Bacik
    Cc: Richard Purdie
    Cc: Vasily Gorbik
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mikhail Zaslonko
     
  • aa5b395b6   lib/zlib: add s390 hardware support for kernel zlib_deflate ... Browse Code »

    Patch series "S390 hardware support for kernel zlib", v3.

    With IBM z15 mainframe the new DFLTCC instruction is available. It
    implements deflate algorithm in hardware (Nest Acceleration Unit - NXU)
    with estimated compression and decompression performance orders of
    magnitude faster than the current zlib.

    This patchset adds s390 hardware compression support to kernel zlib.
    The code is based on the userspace zlib implementation:

    https://github.com/madler/zlib/pull/410

    The coding style is also preserved for future maintainability. There is
    only limited set of userspace zlib functions represented in kernel.
    Apart from that, all the memory allocation should be performed in
    advance. Thus, the workarea structures are extended with the parameter
    lists required for the DEFLATE CONVENTION CALL instruction.

    Since kernel zlib itself does not support gzip headers, only Adler-32
    checksum is processed (also can be produced by DFLTCC facility). Like
    it was implemented for userspace, kernel zlib will compress in hardware
    on level 1, and in software on all other levels. Decompression will
    always happen in hardware (when enabled).

    Two DFLTCC compression calls produce the same results only when they
    both are made on machines of the same generation, and when the
    respective buffers have the same offset relative to the start of the
    page. Therefore care should be taken when using hardware compression
    when reproducible results are desired. However it does always produce
    the standard conform output which can be inflated anyway.

    The new kernel command line parameter 'dfltcc' is introduced to
    configure s390 zlib hardware support:

    Format: { on | off | def_only | inf_only | always }
    on: s390 zlib hardware support for compression on
    level 1 and decompression (default)
    off: No s390 zlib hardware support
    def_only: s390 zlib hardware support for deflate
    only (compression on level 1)
    inf_only: s390 zlib hardware support for inflate
    only (decompression)
    always: Same as 'on' but ignores the selected compression
    level always using hardware support (used for debugging)

    The main purpose of the integration of the NXU support into the kernel
    zlib is the use of hardware deflate in btrfs filesystem with on-the-fly
    compression enabled. Apart from that, hardware support can also be used
    during boot for decompressing the kernel or the ramdisk image

    With the patch for btrfs expanding zlib buffer from 1 to 4 pages (patch
    6) the following performance results have been achieved using the
    ramdisk with btrfs. These are relative numbers based on throughput rate
    and compression ratio for zlib level 1:

    Input data Deflate rate Inflate rate Compression ratio
    NXU/Software NXU/Software NXU/Software
    stream of zeroes 1.46 1.02 1.00
    random ASCII data 10.44 3.00 0.96
    ASCII text (dickens) 6,21 3.33 0.94
    binary data (vmlinux) 8,37 3.90 1.02

    This means that s390 hardware deflate can provide up to 10 times faster
    compression (on level 1) and up to 4 times faster decompression (refers
    to all compression levels) for btrfs zlib.

    Disclaimer: Performance results are based on IBM internal tests using DD
    command-line utility on btrfs on a Fedora 30 based internal driver in
    native LPAR on a z15 system. Results may vary based on individual
    workload, configuration and software levels.

    This patch (of 9):

    Create zlib_dfltcc library with the s390 DEFLATE CONVERSION CALL
    implementation and related compression functions. Update zlib_deflate
    functions with the hooks for s390 hardware support and adjust workspace
    structures with extra parameter lists required for hardware deflate.

    Link: http://lkml.kernel.org/r/20200103223334.20669-2-zaslonko@linux.ibm.com
    Signed-off-by: Ilya Leoshkevich
    Signed-off-by: Mikhail Zaslonko
    Co-developed-by: Ilya Leoshkevich
    Cc: Chris Mason
    Cc: Christian Borntraeger
    Cc: David Sterba
    Cc: Eduard Shishkin
    Cc: Heiko Carstens
    Cc: Josef Bacik
    Cc: Richard Purdie
    Cc: Vasily Gorbik
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mikhail Zaslonko
     

21 May, 2019

2 commits

11 Sep, 2015

1 commit

07 Aug, 2014

1 commit

  • 62e7ca528   zlib: clean up some dead code ... Browse Code »

    Cleanup unused `if 0'-ed functions, which have been dead since 2006
    (commits 87c2ce3b9305 ("lib/zlib*: cleanups") by Adrian Bunk and
    4f3865fb57a0 ("zlib_inflate: Upgrade library code to a recent version")
    by Richard Purdie):

    - zlib_deflateSetDictionary
    - zlib_deflateParams
    - zlib_deflateCopy
    - zlib_inflateSync
    - zlib_syncsearch
    - zlib_inflateSetDictionary
    - zlib_inflatePrime

    Signed-off-by: Sergey Senozhatsky
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Sergey Senozhatsky
     

23 Mar, 2011

1 commit

  • 565d76cb7   zlib: slim down zlib_deflate() workspace when possible ... Browse Code »

    Instead of always creating a huge (268K) deflate_workspace with the
    maximum compression parameters (windowBits=15, memLevel=8), allow the
    caller to obtain a smaller workspace by specifying smaller parameter
    values.

    For example, when capturing oops and panic reports to a medium with
    limited capacity, such as NVRAM, compression may be the only way to
    capture the whole report. In this case, a small workspace (24K works
    fine) is a win, whether you allocate the workspace when you need it (i.e.,
    during an oops or panic) or at boot time.

    I've verified that this patch works with all accepted values of windowBits
    (positive and negative), memLevel, and compression level.

    Signed-off-by: Jim Keniston
    Cc: Herbert Xu
    Cc: David Miller
    Cc: Chris Mason
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jim Keniston
     

21 Sep, 2009

1 commit

03 Feb, 2008

1 commit

23 Jun, 2006

1 commit

  • 4f3865fb5   [PATCH] zlib_inflate: Upgrade library code to a recent version ... Browse Code »
    43

    Upgrade the zlib_inflate implementation in the kernel from a patched
    version 1.1.3/4 to a patched 1.2.3.

    The code in the kernel is about seven years old and I noticed that the
    external zlib library's inflate performance was significantly faster (~50%)
    than the code in the kernel on ARM (and faster again on x86_32).

    For comparison the newer deflate code is 20% slower on ARM and 50% slower
    on x86_32 but gives an approx 1% compression ratio improvement. I don't
    consider this to be an improvement for kernel use so have no plans to
    change the zlib_deflate code.

    Various changes have been made to the zlib code in the kernel, the most
    significant being the extra functions/flush option used by ppp_deflate.
    This update reimplements the features PPP needs to ensure it continues to
    work.

    This code has been tested on ARM under both JFFS2 (with zlib compression
    enabled) and ppp_deflate and on x86_32. JFFS2 sees an approx. 10% real
    world file read speed improvement.

    This patch also removes ZLIB_VERSION as it no longer has a correct value.
    We don't need version checks anyway as the kernel's module handling will
    take care of that for us. This removal is also more in keeping with the
    zlib author's wishes (http://www.zlib.net/zlib_faq.html#faq24) and I've
    added something to the zlib.h header to note its a modified version.

    Signed-off-by: Richard Purdie
    Acked-by: Joern Engel
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Richard Purdie
     

11 Jan, 2006

1 commit

  • 87c2ce3b9   [PATCH] lib/zlib*: cleanups ... Browse Code »

    This patch contains the following possible cleanups:
    - #if 0 the following unused functions:
    - zlib_deflate/deflate.c: zlib_deflateSetDictionary
    - zlib_deflate/deflate.c: zlib_deflateParams
    - zlib_deflate/deflate.c: zlib_deflateCopy
    - zlib_inflate/infblock.c: zlib_inflate_set_dictionary
    - zlib_inflate/infblock.c: zlib_inflate_blocks_sync_point
    - zlib_inflate/inflate_sync.c: zlib_inflateSync
    - zlib_inflate/inflate_sync.c: zlib_inflateSyncPoint
    - remove the following unneeded EXPORT_SYMBOL's:
    - zlib_deflate/deflate_syms.c: zlib_deflateCopy
    - zlib_deflate/deflate_syms.c: zlib_deflateParams
    - zlib_inflate/inflate_syms.c: zlib_inflateSync
    - zlib_inflate/inflate_syms.c: zlib_inflateSyncPoint

    Signed-off-by: Adrian Bunk
    Cc: Matt Mackall
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adrian Bunk
     

17 Apr, 2005

1 commit

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

    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