08 Apr, 2014

5 commits

  • When we initialized zcomp with single, we couldn't change
    max_comp_streams without zram reset but current interface doesn't show
    any error to user and even it changes max_comp_streams's value without
    any effect so it would make user very confusing.

    This patch prevents max_comp_streams's change when zcomp was initialized
    as single zcomp and emit the error to user(ex, echo).

    [akpm@linux-foundation.org: don't return with the lock held, per Sergey]
    [fengguang.wu@intel.com: fix coccinelle warnings]
    Signed-off-by: Minchan Kim
    Cc: Nitin Gupta
    Cc: Jerome Marchand
    Acked-by: Sergey Senozhatsky
    Signed-off-by: Fengguang Wu
    Cc: Stephen Rothwell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Minchan Kim
     
  • Add and document `comp_algorithm' device attribute. This attribute allows
    to show supported compression and currently selected compression
    algorithms:

    cat /sys/block/zram0/comp_algorithm
    [lzo] lz4

    and change selected compression algorithm:
    echo lzo > /sys/block/zram0/comp_algorithm

    Signed-off-by: Sergey Senozhatsky
    Acked-by: Minchan Kim
    Cc: Jerome Marchand
    Cc: Nitin Gupta
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Sergey Senozhatsky
     
  • Existing zram (zcomp) implementation has only one compression stream
    (buffer and algorithm private part), so in order to prevent data
    corruption only one write (compress operation) can use this compression
    stream, forcing all concurrent write operations to wait for stream lock
    to be released. This patch changes zcomp to keep a compression streams
    list of user-defined size (via sysfs device attr). Each write operation
    still exclusively holds compression stream, the difference is that we
    can have N write operations (depending on size of streams list)
    executing in parallel. See TEST section later in commit message for
    performance data.

    Introduce struct zcomp_strm_multi and a set of functions to manage
    zcomp_strm stream access. zcomp_strm_multi has a list of idle
    zcomp_strm structs, spinlock to protect idle list and wait queue, making
    it possible to perform parallel compressions.

    The following set of functions added:
    - zcomp_strm_multi_find()/zcomp_strm_multi_release()
    find and release a compression stream, implement required locking
    - zcomp_strm_multi_create()/zcomp_strm_multi_destroy()
    create and destroy zcomp_strm_multi

    zcomp ->strm_find() and ->strm_release() callbacks are set during
    initialisation to zcomp_strm_multi_find()/zcomp_strm_multi_release()
    correspondingly.

    Each time zcomp issues a zcomp_strm_multi_find() call, the following set
    of operations performed:

    - spin lock strm_lock
    - if idle list is not empty, remove zcomp_strm from idle list, spin
    unlock and return zcomp stream pointer to caller
    - if idle list is empty, current adds itself to wait queue. it will be
    awaken by zcomp_strm_multi_release() caller.

    zcomp_strm_multi_release():
    - spin lock strm_lock
    - add zcomp stream to idle list
    - spin unlock, wake up sleeper

    Minchan Kim reported that spinlock-based locking scheme has demonstrated
    a severe perfomance regression for single compression stream case,
    comparing to mutex-based (see https://lkml.org/lkml/2014/2/18/16)

    base spinlock mutex

    ==Initial write ==Initial write ==Initial write
    records: 5 records: 5 records: 5
    avg: 1642424.35 avg: 699610.40 avg: 1655583.71
    std: 39890.95(2.43%) std: 232014.19(33.16%) std: 52293.96
    max: 1690170.94 max: 1163473.45 max: 1697164.75
    min: 1568669.52 min: 573429.88 min: 1553410.23
    ==Rewrite ==Rewrite ==Rewrite
    records: 5 records: 5 records: 5
    avg: 1611775.39 avg: 501406.64 avg: 1684419.11
    std: 17144.58(1.06%) std: 15354.41(3.06%) std: 18367.42
    max: 1641800.95 max: 531356.78 max: 1706445.84
    min: 1593515.27 min: 488817.78 min: 1655335.73

    When only one compression stream available, mutex with spin on owner
    tends to perform much better than frequent wait_event()/wake_up(). This
    is why single stream implemented as a special case with mutex locking.

    Introduce and document zram device attribute max_comp_streams. This
    attr shows and stores current zcomp's max number of zcomp streams
    (max_strm). Extend zcomp's zcomp_create() with `max_strm' parameter.
    `max_strm' limits the number of zcomp_strm structs in compression
    backend's idle list (max_comp_streams).

    max_comp_streams used during initialisation as follows:
    -- passing to zcomp_create() max_strm equals to 1 will initialise zcomp
    using single compression stream zcomp_strm_single (mutex-based locking).
    -- passing to zcomp_create() max_strm greater than 1 will initialise zcomp
    using multi compression stream zcomp_strm_multi (spinlock-based locking).

    default max_comp_streams value is 1, meaning that zram with single stream
    will be initialised.

    Later patch will introduce configuration knob to change max_comp_streams
    on already initialised and used zcomp.

    TEST
    iozone -t 3 -R -r 16K -s 60M -I +Z

    test base 1 strm (mutex) 3 strm (spinlock)
    -----------------------------------------------------------------------
    Initial write 589286.78 583518.39 718011.05
    Rewrite 604837.97 596776.38 1515125.72
    Random write 584120.11 595714.58 1388850.25
    Pwrite 535731.17 541117.38 739295.27
    Fwrite 1418083.88 1478612.72 1484927.06

    Usage example:
    set max_comp_streams to 4
    echo 4 > /sys/block/zram0/max_comp_streams

    show current max_comp_streams (default value is 1).
    cat /sys/block/zram0/max_comp_streams

    Signed-off-by: Sergey Senozhatsky
    Acked-by: Minchan Kim
    Cc: Jerome Marchand
    Cc: Nitin Gupta
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Sergey Senozhatsky
     
  • Document `failed_reads' and `failed_writes' device attributes.
    Remove info about `discard' - there is no such zram attr.

    Signed-off-by: Sergey Senozhatsky
    Cc: Minchan Kim
    Cc: Jerome Marchand
    Cc: Nitin Gupta
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Sergey Senozhatsky
     
  • Move zram warning about disksize and size of memory correlation to zram
    documentation.

    Signed-off-by: Sergey Senozhatsky
    Acked-by: Minchan Kim
    Cc: Jerome Marchand
    Cc: Nitin Gupta
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Sergey Senozhatsky
     

17 Feb, 2014

1 commit


31 Jan, 2014

2 commits

  • Remove the old private compcache project address so upcoming patches
    should be sent to LKML because we Linux kernel community will take care.

    Signed-off-by: Minchan Kim
    Cc: Nitin Gupta
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Minchan Kim
     
  • Zram has lived in staging for a LONG LONG time and have been
    fixed/improved by many contributors so code is clean and stable now. Of
    course, there are lots of product using zram in real practice.

    The major TV companys have used zram as swap since two years ago and
    recently our production team released android smart phone with zram
    which is used as swap, too and recently Android Kitkat start to use zram
    for small memory smart phone. And there was a report Google released
    their ChromeOS with zram, too and cyanogenmod have been used zram long
    time ago. And I heard some disto have used zram block device for tmpfs.
    In addition, I saw many report from many other peoples. For example,
    Lubuntu start to use it.

    The benefit of zram is very clear. With my experience, one of the
    benefit was to remove jitter of video application with backgroud memory
    pressure. It would be effect of efficient memory usage by compression
    but more issue is whether swap is there or not in the system. Recent
    mobile platforms have used JAVA so there are many anonymous pages. But
    embedded system normally are reluctant to use eMMC or SDCard as swap
    because there is wear-leveling and latency issues so if we do not use
    swap, it means we can't reclaim anoymous pages and at last, we could
    encounter OOM kill. :(

    Although we have real storage as swap, it was a problem, too. Because
    it sometime ends up making system very unresponsible caused by slow swap
    storage performance.

    Quote from Luigi on Google
    "Since Chrome OS was mentioned: the main reason why we don't use swap
    to a disk (rotating or SSD) is because it doesn't degrade gracefully
    and leads to a bad interactive experience. Generally we prefer to
    manage RAM at a higher level, by transparently killing and restarting
    processes. But we noticed that zram is fast enough to be competitive
    with the latter, and it lets us make more efficient use of the
    available RAM. " and he announced.
    http://www.spinics.net/lists/linux-mm/msg57717.html

    Other uses case is to use zram for block device. Zram is block device
    so anyone can format the block device and mount on it so some guys on
    the internet start zram as /var/tmp.
    http://forums.gentoo.org/viewtopic-t-838198-start-0.html

    Let's promote zram and enhance/maintain it instead of removing.

    Signed-off-by: Minchan Kim
    Reviewed-by: Konrad Rzeszutek Wilk
    Acked-by: Nitin Gupta
    Acked-by: Pekka Enberg
    Cc: Bob Liu
    Cc: Greg Kroah-Hartman
    Cc: Hugh Dickins
    Cc: Jens Axboe
    Cc: Luigi Semenzato
    Cc: Mel Gorman
    Cc: Rik van Riel
    Cc: Seth Jennings
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Minchan Kim
     

24 Jan, 2014

1 commit


09 Nov, 2013

1 commit


28 Feb, 2013

1 commit

  • Documentation/blockdev/nbd.txt contained some documentation which was
    horribly outdated and probably still dates from the original patch that
    added NBD support to the kernel.

    This patch removes the useless and outdated bits. The tools on nbd.sf.net
    are fully documented in manpages, which is where documentation for the
    non-kernel bits should live.

    Additionally, add a reference to the MAINTAINERS file for the nbd-general
    mailinglist that is used for discussion of the userland tools and the
    kernel module already.

    Signed-off-by: Wouter Verhelst
    Cc: Paul Clements
    Cc: Paolo Bonzini
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Wouter Verhelst
     

31 Mar, 2012

1 commit

  • Usage of /etc/modprobe.conf file was deprecated by module-init-tools and
    is no longer parsed by new kmod tool. References to this file are
    replaced in Documentation, comments and Kconfig according to the
    context.

    There are also some references to the old /etc/modules.conf from 2.4
    kernels that are being removed.

    Signed-off-by: Lucas De Marchi
    Acked-by: Takashi Iwai
    Acked-by: Mauro Carvalho Chehab
    Signed-off-by: Randy Dunlap
    Signed-off-by: Linus Torvalds

    Lucas De Marchi
     

16 Nov, 2011

1 commit

  • A long time ago, probably in 2002, one of the distros, or maybe more than
    one, loaded block drivers prior to loading the SCSI mid layer. This meant
    that the cciss driver, being a block driver, could not engage the SCSI mid
    layer at init time without panicking, and relied on being poked by a
    userland program after the system was up (and the SCSI mid layer was
    therefore present) to engage the SCSI mid layer.

    This is no longer the case, and cciss can safely rely on the SCSI mid
    layer being present at init time and engage the SCSI mid layer straight
    away. This means that users will see their tape drives and medium
    changers at driver load time without need for a script in /etc/rc.d that
    does this:

    for x in /proc/driver/cciss/cciss*
    do
    echo "engage scsi" > $x
    done

    However, if no tape drives or medium changers are detected, the SCSI mid
    layer will not be engaged. If a tape drive or medium change is later
    hot-added to the system it will then be necessary to use the above script
    or similar for the device(s) to be acceesible.

    Signed-off-by: Stephen M. Cameron
    Signed-off-by: Andrew Morton
    Signed-off-by: Jens Axboe

    Stephen M. Cameron
     

08 Aug, 2011

1 commit


13 Jun, 2011

1 commit

  • Change all "arch/i386" to "arch/x86" in Documentaion/,
    since the directory has changed.

    Also update the files which have changed their filename
    in the meantime accordingly.

    Signed-off-by: Wanlong Gao
    [jkosina@suse.cz: reword changelog]
    Signed-off-by: Jiri Kosina

    Wanlong Gao
     

06 May, 2011

1 commit

  • This is to allow number of commands reserved for use by SCSI tape drives
    and medium changers to be adjusted at driver load time via the kernel
    parameter cciss_tape_cmds, with a default value of 6, and a range
    of 2 - 16 inclusive. Previously, the driver limited the number of
    commands which could be queued to the SCSI half of the the driver
    to only 2. This is to fix the problem that if you had more than
    two tape drives, you couldn't, for example, erase or rewind them all
    at the same time.

    Signed-off-by: Stephen M. Cameron
    Signed-off-by: Jens Axboe

    Stephen M. Cameron
     

04 Aug, 2010

1 commit

  • Below you will find an updated version from the original series bunching all patches into one big patch
    updating broken web addresses that are located in Documentation/*
    Some of the addresses date as far far back as 1995 etc... so searching became a bit difficult,
    the best way to deal with these is to use web.archive.org to locate these addresses that are outdated.
    Now there are also some addresses pointing to .spec files some are located, but some(after searching
    on the companies site)where still no where to be found. In this case I just changed the address
    to the company site this way the users can contact the company and they can locate them for the users.

    Signed-off-by: Justin P. Mattock
    Signed-off-by: Thomas Weber
    Signed-off-by: Mike Frysinger
    Cc: Paulo Marques
    Cc: Randy Dunlap
    Cc: Michael Neuling
    Signed-off-by: Jiri Kosina

    Justin P. Mattock
     

02 Oct, 2009

1 commit


07 Apr, 2009

1 commit

  • This driver supports mflash IO mode for linux.

    Mflash is embedded flash drive and mainly targeted mobile and consumer
    electronic devices.

    Internally, mflash has nand flash and other hardware logics and supports 2
    different operation (ATA, IO) modes. ATA mode doesn't need any new driver
    and currently works well under standard IDE subsystem. Actually it's one
    chip SSD. IO mode is ATA-like custom mode for the host that doesn't have
    IDE interface.

    Followings are brief descriptions about IO mode.
    A. IO mode based on ATA protocol and uses some custom command. (read confirm,
    write confirm)
    B. IO mode uses SRAM bus interface.
    C. IO mode supports 4kB boot area, so host can boot from mflash.

    This driver is quitely similar to a standard ATA driver, but because of
    following reasons it is currently seperated with ATA layer.

    1. ATA layer deals standard ATA protocol. ATA layer have many low-
    level device specific interface, but data transfer keeps ATA rule.
    But, mflash IO mode doesn't.

    2. Even though currently not used in mflash driver code, mflash has
    some custom command and modes. (nand fusing, firmware patch, etc) If
    this feature supported in linux kernel, ATA layer more altered.

    3. Currently PATA platform device driver doesn't support interrupt.
    (I'm not sure) But, mflash uses interrupt (polling mode is just for
    debug).

    4. mflash is somewhat under-develop product. Even though some company
    already using mflash their own product, I think more time is needed for
    standardization of custom command and mode. That time (maybe October)
    I will talk to with ATA people. If they accept integration, I will
    integrate.

    Signed-off-by: unsik Kim
    Cc: Alan Cox
    Signed-off-by: Andrew Morton
    Signed-off-by: Jens Axboe

    unsik Kim
     

15 Nov, 2008

1 commit