diff options
author | Miklos Szeredi <mszeredi@suse.cz> | 2010-12-07 20:16:56 +0100 |
---|---|---|
committer | Miklos Szeredi <mszeredi@suse.cz> | 2010-12-07 20:16:56 +0100 |
commit | 07e77dca8a1f17a724a9b7449f0ca02e70e9d057 (patch) | |
tree | 69186be641145fd997ce15e17a22598d9a264119 /include/linux/fuse.h | |
parent | 8ac835056ca39b242d98332f46e4d65428a8b7db (diff) | |
download | talos-op-linux-07e77dca8a1f17a724a9b7449f0ca02e70e9d057.tar.gz talos-op-linux-07e77dca8a1f17a724a9b7449f0ca02e70e9d057.zip |
fuse: separate queue for FORGET requests
Terje Malmedal reports that a fuse filesystem with 32 million inodes
on a machine with lots of memory can go unresponsive for up to 30
minutes when all those inodes are evicted from the icache.
The reason is that FORGET messages, sent when the inode is evicted,
are queued up together with regular filesystem requests, and while the
huge queue of FORGET messages are processed no other filesystem
operation can proceed.
Since a full fuse request structure is allocated for each inode, these
take up quite a bit of memory as well.
To solve these issues, create a slim 'fuse_forget_link' structure
containing just the minimum of information required to send the FORGET
request and chain these on a separate queue.
When userspace is asking for a request make sure that FORGET and
non-FORGET requests are selected fairly: for each 8 non-FORGET allow
16 FORGET requests. This will make sure FORGETs do not pile up, yet
other requests are also allowed to proceed while the queued FORGETs
are processed.
Reported-by: Terje Malmedal <terje.malmedal@usit.uio.no>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Diffstat (limited to 'include/linux/fuse.h')
0 files changed, 0 insertions, 0 deletions