1. 14 Jan, 2011 1 commit
  2. 22 Jul, 2010 1 commit
    • Tejun Heo's avatar
      fscache: convert operation to use workqueue instead of slow-work · 8af7c124
      Tejun Heo authored
      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
      * debugfs support is dropped for now.  Tracing API based debug
        facility is planned to be added.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarDavid Howells <dhowells@redhat.com>
  3. 30 Mar, 2010 1 commit
    • Tejun Heo's avatar
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo authored
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit 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.
      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
  4. 29 Mar, 2010 1 commit
  5. 19 Nov, 2009 5 commits
    • David Howells's avatar
      FS-Cache: Handle read request vs lookup, creation or other cache failure · e3d4d28b
      David Howells authored
      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:
      	 [<ffffffffa0076477>] fscache_submit_op+0x3ff/0x45a [fscache]
      	 [<ffffffffa0077997>] __fscache_read_or_alloc_pages+0x187/0x3c4 [fscache]
      	 [<ffffffffa00b6480>] ? nfs_readpage_from_fscache_complete+0x0/0x66 [nfs]
      	 [<ffffffffa00b6388>] __nfs_readpages_from_fscache+0x7e/0x176 [nfs]
      	 [<ffffffff8108e483>] ? __alloc_pages_nodemask+0x11c/0x5cf
      	 [<ffffffffa009d796>] nfs_readpages+0x114/0x1d7 [nfs]
      	 [<ffffffff81090314>] __do_page_cache_readahead+0x15f/0x1ec
      	 [<ffffffff81090228>] ? __do_page_cache_readahead+0x73/0x1ec
      	 [<ffffffff810903bd>] ra_submit+0x1c/0x20
      	 [<ffffffff810906bb>] ondemand_readahead+0x227/0x23a
      	 [<ffffffff81090762>] page_cache_sync_readahead+0x17/0x19
      	 [<ffffffff8108a99e>] generic_file_aio_read+0x236/0x5a0
      	 [<ffffffffa00937bd>] nfs_file_read+0xe4/0xf3 [nfs]
      	 [<ffffffff810b2fa2>] do_sync_read+0xe3/0x120
      	 [<ffffffff81354cc3>] ? _spin_unlock_irq+0x2b/0x31
      	 [<ffffffff8104c0f1>] ? autoremove_wake_function+0x0/0x34
      	 [<ffffffff811848e5>] ? selinux_file_permission+0x5d/0x10f
      	 [<ffffffff81352bdb>] ? thread_return+0x3e/0x101
      	 [<ffffffff8117d7b0>] ? security_file_permission+0x11/0x13
      	 [<ffffffff810b3b06>] vfs_read+0xaa/0x16f
      	 [<ffffffff81058df0>] ? trace_hardirqs_on_caller+0x10c/0x130
      	 [<ffffffff810b3c84>] sys_read+0x45/0x6c
      	 [<ffffffff8100ae2b>] 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: default avatarDavid Howells <dhowells@redhat.com>
    • David Howells's avatar
      FS-Cache: Permit cache retrieval ops to be interrupted in the initial wait phase · 5753c441
      David Howells authored
      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
      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: default avatarDavid Howells <dhowells@redhat.com>
    • David Howells's avatar
      FS-Cache: Allow the current state of all objects to be dumped · 4fbf4291
      David Howells authored
      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
      	keyctl add user fscache:objlist "<restrictions>" @s
      The <restrictions> 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
      	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: default avatarDavid Howells <dhowells@redhat.com>
    • David Howells's avatar
      FS-Cache: Annotate slow-work runqueue proc lines for FS-Cache work items · 440f0aff
      David Howells authored
      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: default avatarDavid Howells <dhowells@redhat.com>
    • David Howells's avatar
      SLOW_WORK: Wait for outstanding work items belonging to a module to clear · 3d7a641e
      David Howells authored
      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: default avatarDavid Howells <dhowells@redhat.com>
  6. 03 Apr, 2009 1 commit
    • David Howells's avatar
      FS-Cache: Add and document asynchronous operation handling · 952efe7b
      David Howells authored
      Add and document asynchronous operation handling for use by FS-Cache's data
      storage and retrieval routines.
      The following documentation is added to:
      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
      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, <linux/fscache-cache.h> should be #included.
      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.
      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
       (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
           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.
      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
      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
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarSteve Dickson <steved@redhat.com>
      Acked-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      Acked-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Tested-by: default avatarDaire Byrne <Daire.Byrne@framestore.com>