25 May, 2011

1 commit


15 Jan, 2011

1 commit

  • fscache_submit_exclusive_op() adds an operation to the pending list if
    other operations are pending. Fix the check for pending ops as n_ops
    must be greater than 0 at the point it is checked as it is incremented
    immediately before under lock.

    Signed-off-by: Akshat Aranya
    Signed-off-by: David Howells
    Signed-off-by: Linus Torvalds

    Akshat Aranya
     

23 Jul, 2010

1 commit

  • Make fscache operation to use only workqueue instead of combination of
    workqueue and slow-work. FSCACHE_OP_SLOW is dropped and
    FSCACHE_OP_FAST is renamed to FSCACHE_OP_ASYNC and uses newly added
    fscache_op_wq workqueue to execute op->processor().
    fscache_operation_init_slow() is dropped and fscache_operation_init()
    now takes @processor argument directly.

    * Unbound workqueue is used.

    * fscache_retrieval_work() is no longer necessary as OP_ASYNC now does
    the equivalent thing.

    * sysctl fscache.operation_max_active added to control concurrency.
    The default value is nr_cpus clamped between 2 and
    WQ_UNBOUND_MAX_ACTIVE.

    * debugfs support is dropped for now. Tracing API based debug
    facility is planned to be added.

    Signed-off-by: Tejun Heo
    Acked-by: David Howells

    Tejun Heo
     

30 Mar, 2010

2 commits

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     
  • CONFIG_SLOW_WORK_PROC was changed to CONFIG_SLOW_WORK_DEBUG, but not in all
    instances. Change the remaining instances. This makes the debugfs file
    display the time mark and the owner's description again.

    Signed-off-by: David Howells
    Signed-off-by: Linus Torvalds

    David Howells
     

20 Nov, 2009

5 commits

  • FS-Cache doesn't correctly handle the netfs requesting a read from the cache
    on an object that failed or was withdrawn by the cache. A trace similar to
    the following might be seen:

    CacheFiles: Lookup failed error -105
    [exe ] unexpected submission OP165afe [OBJ6cac OBJECT_LC_DYING]
    [exe ] objstate=OBJECT_LC_DYING [OBJECT_LC_DYING]
    [exe ] objflags=0
    [exe ] objevent=9 [fffffffffffffffb]
    [exe ] ops=0 inp=0 exc=0
    Pid: 6970, comm: exe Not tainted 2.6.32-rc6-cachefs #50
    Call Trace:
    [] fscache_submit_op+0x3ff/0x45a [fscache]
    [] __fscache_read_or_alloc_pages+0x187/0x3c4 [fscache]
    [] ? nfs_readpage_from_fscache_complete+0x0/0x66 [nfs]
    [] __nfs_readpages_from_fscache+0x7e/0x176 [nfs]
    [] ? __alloc_pages_nodemask+0x11c/0x5cf
    [] nfs_readpages+0x114/0x1d7 [nfs]
    [] __do_page_cache_readahead+0x15f/0x1ec
    [] ? __do_page_cache_readahead+0x73/0x1ec
    [] ra_submit+0x1c/0x20
    [] ondemand_readahead+0x227/0x23a
    [] page_cache_sync_readahead+0x17/0x19
    [] generic_file_aio_read+0x236/0x5a0
    [] nfs_file_read+0xe4/0xf3 [nfs]
    [] do_sync_read+0xe3/0x120
    [] ? _spin_unlock_irq+0x2b/0x31
    [] ? autoremove_wake_function+0x0/0x34
    [] ? selinux_file_permission+0x5d/0x10f
    [] ? thread_return+0x3e/0x101
    [] ? security_file_permission+0x11/0x13
    [] vfs_read+0xaa/0x16f
    [] ? trace_hardirqs_on_caller+0x10c/0x130
    [] sys_read+0x45/0x6c
    [] system_call_fastpath+0x16/0x1b

    The object state might also be OBJECT_DYING or OBJECT_WITHDRAWING.

    This should be handled by simply rejecting the new operation with ENOBUFS.
    There's no need to log an error for it. Events of this type now appear in the
    stats file under Ops:rej.

    Signed-off-by: David Howells

    David Howells
     
  • Permit the operations to retrieve data from the cache or to allocate space in
    the cache for future writes to be interrupted whilst they're waiting for
    permission for the operation to proceed. Typically this wait occurs whilst the
    cache object is being looked up on disk in the background.

    If an interruption occurs, and the operation has not yet been given the
    go-ahead to run, the operation is dequeued and cancelled, and control returns
    to the read operation of the netfs routine with none of the requested pages
    having been read or in any way marked as known by the cache.

    This means that the initial wait is done interruptibly rather than
    uninterruptibly.

    In addition, extra stats values are made available to show the number of ops
    cancelled and the number of cache space allocations interrupted.

    Signed-off-by: David Howells

    David Howells
     
  • Allow the current state of all fscache objects to be dumped by doing:

    cat /proc/fs/fscache/objects

    By default, all objects and all fields will be shown. This can be restricted
    by adding a suitable key to one of the caller's keyrings (such as the session
    keyring):

    keyctl add user fscache:objlist "" @s

    The are:

    K Show hexdump of object key (don't show if not given)
    A Show hexdump of object aux data (don't show if not given)

    And paired restrictions:

    C Show objects that have a cookie
    c Show objects that don't have a cookie
    B Show objects that are busy
    b Show objects that aren't busy
    W Show objects that have pending writes
    w Show objects that don't have pending writes
    R Show objects that have outstanding reads
    r Show objects that don't have outstanding reads
    S Show objects that have slow work queued
    s Show objects that don't have slow work queued

    If neither side of a restriction pair is given, then both are implied. For
    example:

    keyctl add user fscache:objlist KB @s

    shows objects that are busy, and lists their object keys, but does not dump
    their auxiliary data. It also implies "CcWwRrSs", but as 'B' is given, 'b' is
    not implied.

    Signed-off-by: David Howells

    David Howells
     
  • Annotate slow-work runqueue proc lines for FS-Cache work items. Objects
    include the object ID and the state. Operations include the object ID, the
    operation ID and the operation type and state.

    Signed-off-by: David Howells

    David Howells
     
  • Wait for outstanding slow work items belonging to a module to clear when
    unregistering that module as a user of the facility. This prevents the put_ref
    code of a work item from being taken away before it returns.

    Signed-off-by: David Howells

    David Howells
     

03 Apr, 2009

1 commit

  • Add and document asynchronous operation handling for use by FS-Cache's data
    storage and retrieval routines.

    The following documentation is added to:

    Documentation/filesystems/caching/operations.txt

    ================================
    ASYNCHRONOUS OPERATIONS HANDLING
    ================================

    ========
    OVERVIEW
    ========

    FS-Cache has an asynchronous operations handling facility that it uses for its
    data storage and retrieval routines. Its operations are represented by
    fscache_operation structs, though these are usually embedded into some other
    structure.

    This facility is available to and expected to be be used by the cache backends,
    and FS-Cache will create operations and pass them off to the appropriate cache
    backend for completion.

    To make use of this facility, should be #included.

    ===============================
    OPERATION RECORD INITIALISATION
    ===============================

    An operation is recorded in an fscache_operation struct:

    struct fscache_operation {
    union {
    struct work_struct fast_work;
    struct slow_work slow_work;
    };
    unsigned long flags;
    fscache_operation_processor_t processor;
    ...
    };

    Someone wanting to issue an operation should allocate something with this
    struct embedded in it. They should initialise it by calling:

    void fscache_operation_init(struct fscache_operation *op,
    fscache_operation_release_t release);

    with the operation to be initialised and the release function to use.

    The op->flags parameter should be set to indicate the CPU time provision and
    the exclusivity (see the Parameters section).

    The op->fast_work, op->slow_work and op->processor flags should be set as
    appropriate for the CPU time provision (see the Parameters section).

    FSCACHE_OP_WAITING may be set in op->flags prior to each submission of the
    operation and waited for afterwards.

    ==========
    PARAMETERS
    ==========

    There are a number of parameters that can be set in the operation record's flag
    parameter. There are three options for the provision of CPU time in these
    operations:

    (1) The operation may be done synchronously (FSCACHE_OP_MYTHREAD). A thread
    may decide it wants to handle an operation itself without deferring it to
    another thread.

    This is, for example, used in read operations for calling readpages() on
    the backing filesystem in CacheFiles. Although readpages() does an
    asynchronous data fetch, the determination of whether pages exist is done
    synchronously - and the netfs does not proceed until this has been
    determined.

    If this option is to be used, FSCACHE_OP_WAITING must be set in op->flags
    before submitting the operation, and the operating thread must wait for it
    to be cleared before proceeding:

    wait_on_bit(&op->flags, FSCACHE_OP_WAITING,
    fscache_wait_bit, TASK_UNINTERRUPTIBLE);

    (2) The operation may be fast asynchronous (FSCACHE_OP_FAST), in which case it
    will be given to keventd to process. Such an operation is not permitted
    to sleep on I/O.

    This is, for example, used by CacheFiles to copy data from a backing fs
    page to a netfs page after the backing fs has read the page in.

    If this option is used, op->fast_work and op->processor must be
    initialised before submitting the operation:

    INIT_WORK(&op->fast_work, do_some_work);

    (3) The operation may be slow asynchronous (FSCACHE_OP_SLOW), in which case it
    will be given to the slow work facility to process. Such an operation is
    permitted to sleep on I/O.

    This is, for example, used by FS-Cache to handle background writes of
    pages that have just been fetched from a remote server.

    If this option is used, op->slow_work and op->processor must be
    initialised before submitting the operation:

    fscache_operation_init_slow(op, processor)

    Furthermore, operations may be one of two types:

    (1) Exclusive (FSCACHE_OP_EXCLUSIVE). Operations of this type may not run in
    conjunction with any other operation on the object being operated upon.

    An example of this is the attribute change operation, in which the file
    being written to may need truncation.

    (2) Shareable. Operations of this type may be running simultaneously. It's
    up to the operation implementation to prevent interference between other
    operations running at the same time.

    =========
    PROCEDURE
    =========

    Operations are used through the following procedure:

    (1) The submitting thread must allocate the operation and initialise it
    itself. Normally this would be part of a more specific structure with the
    generic op embedded within.

    (2) The submitting thread must then submit the operation for processing using
    one of the following two functions:

    int fscache_submit_op(struct fscache_object *object,
    struct fscache_operation *op);

    int fscache_submit_exclusive_op(struct fscache_object *object,
    struct fscache_operation *op);

    The first function should be used to submit non-exclusive ops and the
    second to submit exclusive ones. The caller must still set the
    FSCACHE_OP_EXCLUSIVE flag.

    If successful, both functions will assign the operation to the specified
    object and return 0. -ENOBUFS will be returned if the object specified is
    permanently unavailable.

    The operation manager will defer operations on an object that is still
    undergoing lookup or creation. The operation will also be deferred if an
    operation of conflicting exclusivity is in progress on the object.

    If the operation is asynchronous, the manager will retain a reference to
    it, so the caller should put their reference to it by passing it to:

    void fscache_put_operation(struct fscache_operation *op);

    (3) If the submitting thread wants to do the work itself, and has marked the
    operation with FSCACHE_OP_MYTHREAD, then it should monitor
    FSCACHE_OP_WAITING as described above and check the state of the object if
    necessary (the object might have died whilst the thread was waiting).

    When it has finished doing its processing, it should call
    fscache_put_operation() on it.

    (4) The operation holds an effective lock upon the object, preventing other
    exclusive ops conflicting until it is released. The operation can be
    enqueued for further immediate asynchronous processing by adjusting the
    CPU time provisioning option if necessary, eg:

    op->flags &= ~FSCACHE_OP_TYPE;
    op->flags |= ~FSCACHE_OP_FAST;

    and calling:

    void fscache_enqueue_operation(struct fscache_operation *op)

    This can be used to allow other things to have use of the worker thread
    pools.

    =====================
    ASYNCHRONOUS CALLBACK
    =====================

    When used in asynchronous mode, the worker thread pool will invoke the
    processor method with a pointer to the operation. This should then get at the
    container struct by using container_of():

    static void fscache_write_op(struct fscache_operation *_op)
    {
    struct fscache_storage *op =
    container_of(_op, struct fscache_storage, op);
    ...
    }

    The caller holds a reference on the operation, and will invoke
    fscache_put_operation() when the processor function returns. The processor
    function is at liberty to call fscache_enqueue_operation() or to take extra
    references.

    Signed-off-by: David Howells
    Acked-by: Steve Dickson
    Acked-by: Trond Myklebust
    Acked-by: Al Viro
    Tested-by: Daire Byrne

    David Howells