)]}' { "log": [ { "commit": "cc4fc29e59c386919a7674e203be7822dc968dc0", "tree": "b20f18950bc9e7c2a79a6694bae221dd48b9fdf7", "parents": [ "08dc179b9b00cfbed006ae6f5d0e471ef79dc69c" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Tue Apr 06 14:35:09 2010 -0700" }, "committer": { "name": "Linus Torvalds", "email": "torvalds@linux-foundation.org", "time": "Wed Apr 07 08:38:05 2010 -0700" }, "message": "fs-cache: order the debugfs stats correctly\n\nOrder the debugfs statistics correctly. The values displayed through a\nseq_printf() statement should be in the same order as the names in the\nformat string.\n\nIn the \u0027Lookups\u0027 line, objects created (\u0027crt\u003d\u0027) and lookups timed out\n(\u0027tmo\u003d\u0027) have their values transposed.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n" }, { "commit": "fee096deb4f33897937b974cb2c5168bab7935be", "tree": "c86e5ed5b3435ff0f0266f343b19f8cc7be63340", "parents": [ "d0e27b7808dc667f3015be0b6888f6d680e222c8" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:12:05 2009 +0000" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:12:05 2009 +0000" }, "message": "CacheFiles: Catch an overly long wait for an old active object\n\nCatch an overly long wait for an old, dying active object when we want to\nreplace it with a new one. The probability is that all the slow-work threads\nare hogged, and the delete can\u0027t get a look in.\n\nWhat we do instead is:\n\n (1) if there\u0027s nothing in the slow work queue, we sleep until either the dying\n object has finished dying or there is something in the slow work queue\n behind which we can queue our object.\n\n (2) if there is something in the slow work queue, we return ETIMEDOUT to\n fscache_lookup_object(), which then puts us back on the slow work queue,\n presumably behind the deletion that we\u0027re blocked by. We are then\n deferred for a while until we work our way back through the queue -\n without blocking a slow-work thread unnecessarily.\n\nA backtrace similar to the following may appear in the log without this patch:\n\n\tINFO: task kslowd004:5711 blocked for more than 120 seconds.\n\t\"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n\tkslowd004 D 0000000000000000 0 5711 2 0x00000080\n\t ffff88000340bb80 0000000000000046 ffff88002550d000 0000000000000000\n\t ffff88002550d000 0000000000000007 ffff88000340bfd8 ffff88002550d2a8\n\t 000000000000ddf0 00000000000118c0 00000000000118c0 ffff88002550d2a8\n\tCall Trace:\n\t [\u003cffffffff81058e21\u003e] ? trace_hardirqs_on+0xd/0xf\n\t [\u003cffffffffa011c4d8\u003e] ? cachefiles_wait_bit+0x0/0xd [cachefiles]\n\t [\u003cffffffffa011c4e1\u003e] cachefiles_wait_bit+0x9/0xd [cachefiles]\n\t [\u003cffffffff81353153\u003e] __wait_on_bit+0x43/0x76\n\t [\u003cffffffff8111ae39\u003e] ? ext3_xattr_get+0x1ec/0x270\n\t [\u003cffffffff813531ef\u003e] out_of_line_wait_on_bit+0x69/0x74\n\t [\u003cffffffffa011c4d8\u003e] ? cachefiles_wait_bit+0x0/0xd [cachefiles]\n\t [\u003cffffffff8104c125\u003e] ? wake_bit_function+0x0/0x2e\n\t [\u003cffffffffa011bc79\u003e] cachefiles_mark_object_active+0x203/0x23b [cachefiles]\n\t [\u003cffffffffa011c209\u003e] cachefiles_walk_to_object+0x558/0x827 [cachefiles]\n\t [\u003cffffffffa011a429\u003e] cachefiles_lookup_object+0xac/0x12a [cachefiles]\n\t [\u003cffffffffa00aa1e9\u003e] fscache_lookup_object+0x1c7/0x214 [fscache]\n\t [\u003cffffffffa00aafc5\u003e] fscache_object_state_machine+0xa5/0x52d [fscache]\n\t [\u003cffffffffa00ab4ac\u003e] fscache_object_slow_work_execute+0x5f/0xa0 [fscache]\n\t [\u003cffffffff81082093\u003e] slow_work_execute+0x18f/0x2d1\n\t [\u003cffffffff8108239a\u003e] slow_work_thread+0x1c5/0x308\n\t [\u003cffffffff8104c0f1\u003e] ? autoremove_wake_function+0x0/0x34\n\t [\u003cffffffff810821d5\u003e] ? slow_work_thread+0x0/0x308\n\t [\u003cffffffff8104be91\u003e] kthread+0x7a/0x82\n\t [\u003cffffffff8100beda\u003e] child_rip+0xa/0x20\n\t [\u003cffffffff8100b87c\u003e] ? restore_args+0x0/0x30\n\t [\u003cffffffff8104be17\u003e] ? kthread+0x0/0x82\n\t [\u003cffffffff8100bed0\u003e] ? child_rip+0x0/0x20\n\t1 lock held by kslowd004/5711:\n\t #0: (\u0026sb-\u003es_type-\u003ei_mutex_key#7/1){+.+.+.}, at: [\u003cffffffffa011be64\u003e] cachefiles_walk_to_object+0x1b3/0x827 [cachefiles]\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\n" }, { "commit": "60d543ca724be155c2b6166e36a00c80b21bd810", "tree": "90ec6edd77ddb7666dbf7069aa2e001f155cea49", "parents": [ "d461d26dde901b0523c46b0317e7fccf574a3933" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:45 2009 +0000" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:45 2009 +0000" }, "message": "FS-Cache: Start processing an object\u0027s operations on that object\u0027s death\n\nStart processing an object\u0027s operations when that object moves into the DYING\nstate as the object cannot be destroyed until all its outstanding operations\nhave completed.\n\nFurthermore, make sure that read and allocation operations handle being woken\nup on a dead object. Such events are recorded in the Allocs.abt and\nRetrvls.abt statistics as viewable through /proc/fs/fscache/stats.\n\nThe code for waiting for object activation for the read and allocation\noperations is also extracted into its own function as it is much the same in\nall cases, differing only in the stats incremented.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\n" }, { "commit": "2175bb06dc6cf2af9c098a1770561f9e63edae4e", "tree": "579c8d4b3f4f92efee919953dab2c78cea8c21ea", "parents": [ "201a15428bd54f83eccec8b7c64a04b8f9431204" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:38 2009 +0000" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:38 2009 +0000" }, "message": "FS-Cache: Add a retirement stat counter\n\nAdd a stat counter to count retirement events rather than ordinary release\nevents (the retire argument to fscache_relinquish_cookie()).\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\n" }, { "commit": "201a15428bd54f83eccec8b7c64a04b8f9431204", "tree": "326fcce64ce96657253fd141a3f4a767ac95418a", "parents": [ "e3d4d28b1c8cc7c26536a50b43d86ccd39878550" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:35 2009 +0000" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:35 2009 +0000" }, "message": "FS-Cache: Handle pages pending storage that get evicted under OOM conditions\n\nHandle netfs pages that the vmscan algorithm wants to evict from the pagecache\nunder OOM conditions, but that are waiting for write to the cache. Under these\nconditions, vmscan calls the releasepage() function of the netfs, asking if a\npage can be discarded.\n\nThe problem is typified by the following trace of a stuck process:\n\n\tkslowd005 D 0000000000000000 0 4253 2 0x00000080\n\t ffff88001b14f370 0000000000000046 ffff880020d0d000 0000000000000007\n\t 0000000000000006 0000000000000001 ffff88001b14ffd8 ffff880020d0d2a8\n\t 000000000000ddf0 00000000000118c0 00000000000118c0 ffff880020d0d2a8\n\tCall Trace:\n\t [\u003cffffffffa00782d8\u003e] __fscache_wait_on_page_write+0x8b/0xa7 [fscache]\n\t [\u003cffffffff8104c0f1\u003e] ? autoremove_wake_function+0x0/0x34\n\t [\u003cffffffffa0078240\u003e] ? __fscache_check_page_write+0x63/0x70 [fscache]\n\t [\u003cffffffffa00b671d\u003e] nfs_fscache_release_page+0x4e/0xc4 [nfs]\n\t [\u003cffffffffa00927f0\u003e] nfs_release_page+0x3c/0x41 [nfs]\n\t [\u003cffffffff810885d3\u003e] try_to_release_page+0x32/0x3b\n\t [\u003cffffffff81093203\u003e] shrink_page_list+0x316/0x4ac\n\t [\u003cffffffff8109372b\u003e] shrink_inactive_list+0x392/0x67c\n\t [\u003cffffffff813532fa\u003e] ? __mutex_unlock_slowpath+0x100/0x10b\n\t [\u003cffffffff81058df0\u003e] ? trace_hardirqs_on_caller+0x10c/0x130\n\t [\u003cffffffff8135330e\u003e] ? mutex_unlock+0x9/0xb\n\t [\u003cffffffff81093aa2\u003e] shrink_list+0x8d/0x8f\n\t [\u003cffffffff81093d1c\u003e] shrink_zone+0x278/0x33c\n\t [\u003cffffffff81052d6c\u003e] ? ktime_get_ts+0xad/0xba\n\t [\u003cffffffff81094b13\u003e] try_to_free_pages+0x22e/0x392\n\t [\u003cffffffff81091e24\u003e] ? isolate_pages_global+0x0/0x212\n\t [\u003cffffffff8108e743\u003e] __alloc_pages_nodemask+0x3dc/0x5cf\n\t [\u003cffffffff81089529\u003e] grab_cache_page_write_begin+0x65/0xaa\n\t [\u003cffffffff8110f8c0\u003e] ext3_write_begin+0x78/0x1eb\n\t [\u003cffffffff81089ec5\u003e] generic_file_buffered_write+0x109/0x28c\n\t [\u003cffffffff8103cb69\u003e] ? current_fs_time+0x22/0x29\n\t [\u003cffffffff8108a509\u003e] __generic_file_aio_write+0x350/0x385\n\t [\u003cffffffff8108a588\u003e] ? generic_file_aio_write+0x4a/0xae\n\t [\u003cffffffff8108a59e\u003e] generic_file_aio_write+0x60/0xae\n\t [\u003cffffffff810b2e82\u003e] do_sync_write+0xe3/0x120\n\t [\u003cffffffff8104c0f1\u003e] ? autoremove_wake_function+0x0/0x34\n\t [\u003cffffffff810b18e1\u003e] ? __dentry_open+0x1a5/0x2b8\n\t [\u003cffffffff810b1a76\u003e] ? dentry_open+0x82/0x89\n\t [\u003cffffffffa00e693c\u003e] cachefiles_write_page+0x298/0x335 [cachefiles]\n\t [\u003cffffffffa0077147\u003e] fscache_write_op+0x178/0x2c2 [fscache]\n\t [\u003cffffffffa0075656\u003e] fscache_op_execute+0x7a/0xd1 [fscache]\n\t [\u003cffffffff81082093\u003e] slow_work_execute+0x18f/0x2d1\n\t [\u003cffffffff8108239a\u003e] slow_work_thread+0x1c5/0x308\n\t [\u003cffffffff8104c0f1\u003e] ? autoremove_wake_function+0x0/0x34\n\t [\u003cffffffff810821d5\u003e] ? slow_work_thread+0x0/0x308\n\t [\u003cffffffff8104be91\u003e] kthread+0x7a/0x82\n\t [\u003cffffffff8100beda\u003e] child_rip+0xa/0x20\n\t [\u003cffffffff8100b87c\u003e] ? restore_args+0x0/0x30\n\t [\u003cffffffff8102ef83\u003e] ? tg_shares_up+0x171/0x227\n\t [\u003cffffffff8104be17\u003e] ? kthread+0x0/0x82\n\t [\u003cffffffff8100bed0\u003e] ? child_rip+0x0/0x20\n\nIn the above backtrace, the following is happening:\n\n (1) A page storage operation is being executed by a slow-work thread\n (fscache_write_op()).\n\n (2) FS-Cache farms the operation out to the cache to perform\n (cachefiles_write_page()).\n\n (3) CacheFiles is then calling Ext3 to perform the actual write, using Ext3\u0027s\n standard write (do_sync_write()) under KERNEL_DS directly from the netfs\n page.\n\n (4) However, for Ext3 to perform the write, it must allocate some memory, in\n particular, it must allocate at least one page cache page into which it\n can copy the data from the netfs page.\n\n (5) Under OOM conditions, the memory allocator can\u0027t immediately come up with\n a page, so it uses vmscan to find something to discard\n (try_to_free_pages()).\n\n (6) vmscan finds a clean netfs page it might be able to discard (possibly the\n one it\u0027s trying to write out).\n\n (7) The netfs is called to throw the page away (nfs_release_page()) - but it\u0027s\n called with __GFP_WAIT, so the netfs decides to wait for the store to\n complete (__fscache_wait_on_page_write()).\n\n (8) This blocks a slow-work processing thread - possibly against itself.\n\nThe system ends up stuck because it can\u0027t write out any netfs pages to the\ncache without allocating more memory.\n\nTo avoid this, we make FS-Cache cancel some writes that aren\u0027t in the middle of\nactually being performed. This means that some data won\u0027t make it into the\ncache this time. To support this, a new FS-Cache function is added\nfscache_maybe_release_page() that replaces what the netfs releasepage()\nfunctions used to do with respect to the cache.\n\nThe decisions fscache_maybe_release_page() makes are counted and displayed\nthrough /proc/fs/fscache/stats on a line labelled \"VmScan\". There are four\ncounters provided: \"nos\u003dN\" - pages that weren\u0027t pending storage; \"gon\u003dN\" -\npages that were pending storage when we first looked, but weren\u0027t by the time\nwe got the object lock; \"bsy\u003dN\" - pages that we ignored as they were actively\nbeing written when we looked; and \"can\u003dN\" - pages that we cancelled the storage\nof.\n\nWhat I\u0027d really like to do is alter the behaviour of the cancellation\nheuristics, depending on how necessary it is to expel pages. If there are\nplenty of other pages that aren\u0027t waiting to be written to the cache that\ncould be ejected first, then it would be nice to hold up on immediate\ncancellation of cache writes - but I don\u0027t see a way of doing that.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\n" }, { "commit": "e3d4d28b1c8cc7c26536a50b43d86ccd39878550", "tree": "23f6dacd5ffdf6c6d01c411517855a41405381b9", "parents": [ "285e728b0ac55b53a673114096168d6f74930167" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:32 2009 +0000" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:32 2009 +0000" }, "message": "FS-Cache: Handle read request vs lookup, creation or other cache failure\n\nFS-Cache doesn\u0027t correctly handle the netfs requesting a read from the cache\non an object that failed or was withdrawn by the cache. A trace similar to\nthe following might be seen:\n\n\tCacheFiles: Lookup failed error -105\n\t[exe ] unexpected submission OP165afe [OBJ6cac OBJECT_LC_DYING]\n\t[exe ] objstate\u003dOBJECT_LC_DYING [OBJECT_LC_DYING]\n\t[exe ] objflags\u003d0\n\t[exe ] objevent\u003d9 [fffffffffffffffb]\n\t[exe ] ops\u003d0 inp\u003d0 exc\u003d0\n\tPid: 6970, comm: exe Not tainted 2.6.32-rc6-cachefs #50\n\tCall Trace:\n\t [\u003cffffffffa0076477\u003e] fscache_submit_op+0x3ff/0x45a [fscache]\n\t [\u003cffffffffa0077997\u003e] __fscache_read_or_alloc_pages+0x187/0x3c4 [fscache]\n\t [\u003cffffffffa00b6480\u003e] ? nfs_readpage_from_fscache_complete+0x0/0x66 [nfs]\n\t [\u003cffffffffa00b6388\u003e] __nfs_readpages_from_fscache+0x7e/0x176 [nfs]\n\t [\u003cffffffff8108e483\u003e] ? __alloc_pages_nodemask+0x11c/0x5cf\n\t [\u003cffffffffa009d796\u003e] nfs_readpages+0x114/0x1d7 [nfs]\n\t [\u003cffffffff81090314\u003e] __do_page_cache_readahead+0x15f/0x1ec\n\t [\u003cffffffff81090228\u003e] ? __do_page_cache_readahead+0x73/0x1ec\n\t [\u003cffffffff810903bd\u003e] ra_submit+0x1c/0x20\n\t [\u003cffffffff810906bb\u003e] ondemand_readahead+0x227/0x23a\n\t [\u003cffffffff81090762\u003e] page_cache_sync_readahead+0x17/0x19\n\t [\u003cffffffff8108a99e\u003e] generic_file_aio_read+0x236/0x5a0\n\t [\u003cffffffffa00937bd\u003e] nfs_file_read+0xe4/0xf3 [nfs]\n\t [\u003cffffffff810b2fa2\u003e] do_sync_read+0xe3/0x120\n\t [\u003cffffffff81354cc3\u003e] ? _spin_unlock_irq+0x2b/0x31\n\t [\u003cffffffff8104c0f1\u003e] ? autoremove_wake_function+0x0/0x34\n\t [\u003cffffffff811848e5\u003e] ? selinux_file_permission+0x5d/0x10f\n\t [\u003cffffffff81352bdb\u003e] ? thread_return+0x3e/0x101\n\t [\u003cffffffff8117d7b0\u003e] ? security_file_permission+0x11/0x13\n\t [\u003cffffffff810b3b06\u003e] vfs_read+0xaa/0x16f\n\t [\u003cffffffff81058df0\u003e] ? trace_hardirqs_on_caller+0x10c/0x130\n\t [\u003cffffffff810b3c84\u003e] sys_read+0x45/0x6c\n\t [\u003cffffffff8100ae2b\u003e] system_call_fastpath+0x16/0x1b\n\nThe object state might also be OBJECT_DYING or OBJECT_WITHDRAWING.\n\nThis should be handled by simply rejecting the new operation with ENOBUFS.\nThere\u0027s no need to log an error for it. Events of this type now appear in the\nstats file under Ops:rej.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\n" }, { "commit": "1bccf513ac49d44604ba1cddcc29f5886e70f1b6", "tree": "096ba75a3d02018c5f6e1857aaf1d41471733850", "parents": [ "6897e3df8fc37bd4a58bbcdef8306da7fc175584" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:25 2009 +0000" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:25 2009 +0000" }, "message": "FS-Cache: Fix lock misorder in fscache_write_op()\n\nFS-Cache has two structs internally for keeping track of the internal state of\na cached file: the fscache_cookie struct, which represents the netfs\u0027s state,\nand fscache_object struct, which represents the cache\u0027s state. Each has a\npointer that points to the other (when both are in existence), and each has a\nspinlock for pointer maintenance.\n\nSince netfs operations approach these structures from the cookie side, they get\nthe cookie lock first, then the object lock. Cache operations, on the other\nhand, approach from the object side, and get the object lock first. It is not\nthen permitted for a cache operation to get the cookie lock whilst it is\nholding the object lock lest deadlock occur; instead, it must do one of two\nthings:\n\n (1) increment the cookie usage counter, drop the object lock and then get both\n locks in order, or\n\n (2) simply hold the object lock as certain parts of the cookie may not be\n altered whilst the object lock is held.\n\nIt is also not permitted to follow either pointer without holding the lock at\nthe end you start with. To break the pointers between the cookie and the\nobject, both locks must be held.\n\nfscache_write_op(), however, violates the locking rules: It attempts to get the\ncookie lock without (a) checking that the cookie pointer is a valid pointer,\nand (b) holding the object lock to protect the cookie pointer whilst it follows\nit. This is so that it can access the pending page store tree without\ninterference from __fscache_write_page().\n\nThis is fixed by splitting the cookie lock, such that the page store tracking\ntree is protected by its own lock, and checking that the cookie pointer is\nnon-NULL before we attempt to follow it whilst holding the object lock.\n\nThe new lock is subordinate to both the cookie lock and the object lock, and so\nshould be taken after those.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\n" }, { "commit": "5753c441889253e4323eee85f791a1d64cf08196", "tree": "55a0de053d0593d96e99710f978277df668412d1", "parents": [ "b34df792b4e9e311db47fad27949095d0629c197" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:19 2009 +0000" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:19 2009 +0000" }, "message": "FS-Cache: Permit cache retrieval ops to be interrupted in the initial wait phase\n\nPermit the operations to retrieve data from the cache or to allocate space in\nthe cache for future writes to be interrupted whilst they\u0027re waiting for\npermission for the operation to proceed. Typically this wait occurs whilst the\ncache object is being looked up on disk in the background.\n\nIf an interruption occurs, and the operation has not yet been given the\ngo-ahead to run, the operation is dequeued and cancelled, and control returns\nto the read operation of the netfs routine with none of the requested pages\nhaving been read or in any way marked as known by the cache.\n\nThis means that the initial wait is done interruptibly rather than\nuninterruptibly.\n\nIn addition, extra stats values are made available to show the number of ops\ncancelled and the number of cache space allocations interrupted.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\n" }, { "commit": "52bd75fdb135d6133d878ae60c6e7e3f4ebc1cfc", "tree": "4fad4fa37ce533c520a4575e5b7df90e19c6a666", "parents": [ "4fbf4291aa15926cd4fdca0ffe9122e89d0459db" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:08 2009 +0000" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:08 2009 +0000" }, "message": "FS-Cache: Add counters for entry/exit to/from cache operation functions\n\nCount entries to and exits from cache operation table functions. Maintain\nthese as a single counter that\u0027s added to or removed from as appropriate.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\n" }, { "commit": "7394daa8c61dfda4baa687f133748fa0b599b017", "tree": "32d2c55ed60596918ec62ce6ecca186337bf4660", "parents": [ "06b3db1b9bccdc8c2c743122a89745279e5ecc46" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Fri Apr 03 16:42:37 2009 +0100" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Fri Apr 03 16:42:37 2009 +0100" }, "message": "FS-Cache: Add use of /proc and presentation of statistics\n\nMake FS-Cache create its /proc interface and present various statistical\ninformation through it. Also provide the functions for updating this\ninformation.\n\nThese features are enabled by:\n\n\tCONFIG_FSCACHE_PROC\n\tCONFIG_FSCACHE_STATS\n\tCONFIG_FSCACHE_HISTOGRAM\n\nThe /proc directory for FS-Cache is also exported so that caching modules can\nadd their own statistics there too.\n\nThe FS-Cache module is loadable at this point, and the statistics files can be\nexamined by userspace:\n\n\tcat /proc/fs/fscache/stats\n\tcat /proc/fs/fscache/histogram\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\nAcked-by: Steve Dickson \u003csteved@redhat.com\u003e\nAcked-by: Trond Myklebust \u003cTrond.Myklebust@netapp.com\u003e\nAcked-by: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\nTested-by: Daire Byrne \u003cDaire.Byrne@framestore.com\u003e\n" } ] }