Doug / smarc-fsl-linux-kernel

21 Oct, 2006

1 commit

  • 3fcfab16c   [PATCH] separate bdi congestion functions from queue congestion functions ... Browse Code »

    Separate out the concept of "queue congestion" from "backing-dev congestion".
    Congestion is a backing-dev concept, not a queue concept.

    The blk_* congestion functions are retained, as wrappers around the core
    backing-dev congestion functions.

    This proper layering is needed so that NFS can cleanly use the congestion
    functions, and so that CONFIG_BLOCK=n actually links.

    Cc: "Thomas Maier"
    Cc: "Jens Axboe"
    Cc: Trond Myklebust
    Cc: David Howells
    Cc: Peter Osterlund
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

04 Oct, 2006

1 commit

01 Oct, 2006

1 commit

30 Sep, 2006

1 commit

26 Sep, 2006

1 commit

23 Sep, 2006

1 commit

23 Jun, 2006

1 commit

  • 111ebb6e6   [PATCH] writeback: fix range handling ... Browse Code »

    When a writeback_control's `start' and `end' fields are used to
    indicate a one-byte-range starting at file offset zero, the required
    values of .start=0,.end=0 mean that the ->writepages() implementation
    has no way of telling that it is being asked to perform a range
    request. Because we're currently overloading (start == 0 && end == 0)
    to mean "this is not a write-a-range request".

    To make all this sane, the patch changes range of writeback_control.

    So caller does: If it is calling ->writepages() to write pages, it
    sets range (range_start/end or range_cyclic) always.

    And if range_cyclic is true, ->writepages() thinks the range is
    cyclic, otherwise it just uses range_start and range_end.

    This patch does,

    - Add LLONG_MAX, LLONG_MIN, ULLONG_MAX to include/linux/kernel.h
    -1 is usually ok for range_end (type is long long). But, if someone did,

    range_end += val; range_end is "val - 1"
    u64val = range_end >> bits; u64val is "~(0ULL)"

    or something, they are wrong. So, this adds LLONG_MAX to avoid nasty
    things, and uses LLONG_MAX for range_end.

    - All callers of ->writepages() sets range_start/end or range_cyclic.

    - Fix updates of ->writeback_index. It seems already bit strange.
    If it starts at 0 and ended by check of nr_to_write, this last
    index may reduce chance to scan end of file. So, this updates
    ->writeback_index only if range_cyclic is true or whole-file is
    scanned.

    Signed-off-by: OGAWA Hirofumi
    Cc: Nathan Scott
    Cc: Anton Altaparmakov
    Cc: Steven French
    Cc: "Vladimir V. Saveliev"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    OGAWA Hirofumi
     

24 Mar, 2006

2 commits

  • fa5a734e4   [PATCH] balance_dirty_pages_ratelimited: take nr_pages arg ... Browse Code »

    Modify balance_dirty_pages_ratelimited() so that it can take a
    number-of-pages-which-I-just-dirtied argument. For msync().

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

    Andrew Morton
     
  • f6ef94381   [PATCH] Represent dirty_*_centisecs as jiffies internally ... Browse Code »

    Make that the internal values for:

    /proc/sys/vm/dirty_writeback_centisecs
    /proc/sys/vm/dirty_expire_centisecs

    are stored as jiffies instead of centiseconds. Let the sysctl interface do
    the conversions with full precision using clock_t_to_jiffies, instead of
    doing overflow-sensitive on-the-fly conversions every time the values are
    used.

    Cons: apparent precision loss if HZ is not a multiple of 100, because of
    conversion back and forth. This is a common problem for all sysctl values
    that use proc_dointvec_userhz_jiffies. (There is only one other in-tree
    use, in net/core/neighbour.c.)

    Signed-off-by: Bart Samwel
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bart Samwel
     

09 Jan, 2006

1 commit

07 Jan, 2006

1 commit

  • 22905f775   identify multipage ->writepages() calls ... Browse Code »

    NFS needs to be able to distinguish between single-page ->writepage() calls and
    multipage ->writepages() calls.

    For the single-page writepage calls NFS can kick off the I/O within the
    context of ->writepage().

    For multipage ->writepages calls, nfs_writepage() will leave the I/O pending
    and nfs_writepages() will kick off the I/O when it all has been queued up
    within NFS.

    Cc: Trond Myklebust
    Signed-off-by: Andrew Morton
    Signed-off-by: Trond Myklebust

    Andrew Morton
     

04 Jan, 2006

1 commit

  • 994fc28c7   [PATCH] add AOP_TRUNCATED_PAGE, prepend AOP_ to WRITEPAGE_ACTIVATE ... Browse Code »

    readpage(), prepare_write(), and commit_write() callers are updated to
    understand the special return code AOP_TRUNCATED_PAGE in the style of
    writepage() and WRITEPAGE_ACTIVATE. AOP_TRUNCATED_PAGE tells the caller that
    the callee has unlocked the page and that the operation should be tried again
    with a new page. OCFS2 uses this to detect and work around a lock inversion in
    its aop methods. There should be no change in behaviour for methods that don't
    return AOP_TRUNCATED_PAGE.

    WRITEPAGE_ACTIVATE is also prepended with AOP_ for consistency and they are
    made enums so that kerneldoc can be used to document their semantics.

    Signed-off-by: Zach Brown

    Zach Brown
     

11 Sep, 2005

1 commit

29 Jun, 2005

1 commit

28 Jun, 2005

1 commit

  • 22e2c507c   [PATCH] Update cfq io scheduler to time sliced design ... Browse Code »

    This updates the CFQ io scheduler to the new time sliced design (cfq
    v3). It provides full process fairness, while giving excellent
    aggregate system throughput even for many competing processes. It
    supports io priorities, either inherited from the cpu nice value or set
    directly with the ioprio_get/set syscalls. The latter closely mimic
    set/getpriority.

    This import is based on my latest from -mm.

    Signed-off-by: Jens Axboe
    Signed-off-by: Linus Torvalds

    Jens Axboe
     

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