From: Jeff Layton <jlayton@poochiereds.net> To: Al Viro <viro@ZenIV.linux.org.uk> Cc: bfields@fieldses.org, linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 0/4] fs: allow userland tasks to use delayed_fput infrastructure Date: Mon, 14 Sep 2015 09:45:51 -0400 [thread overview] Message-ID: <1442238355-8203-1-git-send-email-jeff.layton@primarydata.com> (raw) I'm breaking this piece out of the open file cache work for nfsd to see if we can get this piece settled before I re-post the whole set. If this looks like a reasonable approach we can sort out how it should be merged (either by you directly, or via Bruce's tree with the rest of the open file cache patches). For those just joining in, some background: We want to add an open file cache for nfsd to reduce the open/close overhead on READ/WRITE RPCs, and so we can eliminate the raparm cache. The basic idea is to keep a cache of open files, and close them down on certain sorts of activity -- primarily, after an unlink that takes the link count to 0, or before setting a lease. The setlease part is problematic though. The plan is to have a notifier callback into nfsd from vfs_setlease that will tell nfsd to close any open files that are associated with the inode so we don't block lease attempts solely due to cached but otherwise idle nfsd files. That means that we need to be able to close out the files and ensure that the final __fput runs before we try to set a lease. My latest pass involved making __fput_sync available to userland tasks, but Al had concerns that that could lead to stack blowouts. This patchset is an alternative approach that allows userland tasks to use the delayed_fput infrastructure instead. The idea is that we'd have the pre-setlease notifier do a fput_queue() and then call flush_delayed_fput to ensure that any queued __fput() calls complete before setting the lease. There's also a fix for a potential race in flush_delayed_fput in here and some doc comment cleanups. Al, does this look more acceptable than using __fput_sync? Jeff Layton (4): fs: have flush_delayed_fput flush the workqueue job fs: add a kerneldoc header to fput fs: add fput_queue fs: export flush_delayed_fput fs/file_table.c | 57 +++++++++++++++++++++++++++++++++++++++++----------- include/linux/file.h | 1 + 2 files changed, 46 insertions(+), 12 deletions(-) -- 2.4.3
WARNING: multiple messages have this Message-ID (diff)
From: Jeff Layton <jlayton-vpEMnDpepFuMZCB2o+C8xQ@public.gmane.org> To: Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org> Cc: bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org, linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: [PATCH 0/4] fs: allow userland tasks to use delayed_fput infrastructure Date: Mon, 14 Sep 2015 09:45:51 -0400 [thread overview] Message-ID: <1442238355-8203-1-git-send-email-jeff.layton@primarydata.com> (raw) I'm breaking this piece out of the open file cache work for nfsd to see if we can get this piece settled before I re-post the whole set. If this looks like a reasonable approach we can sort out how it should be merged (either by you directly, or via Bruce's tree with the rest of the open file cache patches). For those just joining in, some background: We want to add an open file cache for nfsd to reduce the open/close overhead on READ/WRITE RPCs, and so we can eliminate the raparm cache. The basic idea is to keep a cache of open files, and close them down on certain sorts of activity -- primarily, after an unlink that takes the link count to 0, or before setting a lease. The setlease part is problematic though. The plan is to have a notifier callback into nfsd from vfs_setlease that will tell nfsd to close any open files that are associated with the inode so we don't block lease attempts solely due to cached but otherwise idle nfsd files. That means that we need to be able to close out the files and ensure that the final __fput runs before we try to set a lease. My latest pass involved making __fput_sync available to userland tasks, but Al had concerns that that could lead to stack blowouts. This patchset is an alternative approach that allows userland tasks to use the delayed_fput infrastructure instead. The idea is that we'd have the pre-setlease notifier do a fput_queue() and then call flush_delayed_fput to ensure that any queued __fput() calls complete before setting the lease. There's also a fix for a potential race in flush_delayed_fput in here and some doc comment cleanups. Al, does this look more acceptable than using __fput_sync? Jeff Layton (4): fs: have flush_delayed_fput flush the workqueue job fs: add a kerneldoc header to fput fs: add fput_queue fs: export flush_delayed_fput fs/file_table.c | 57 +++++++++++++++++++++++++++++++++++++++++----------- include/linux/file.h | 1 + 2 files changed, 46 insertions(+), 12 deletions(-) -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next reply other threads:[~2015-09-14 13:46 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-09-14 13:45 Jeff Layton [this message] 2015-09-14 13:45 ` [PATCH 0/4] fs: allow userland tasks to use delayed_fput infrastructure Jeff Layton 2015-09-14 13:45 ` [PATCH 1/4] fs: have flush_delayed_fput flush the workqueue job Jeff Layton 2015-09-14 13:45 ` [PATCH 2/4] fs: add a kerneldoc header to fput Jeff Layton 2015-09-14 13:45 ` [PATCH 3/4] fs: add fput_queue Jeff Layton 2015-09-14 13:45 ` Jeff Layton 2015-09-14 14:15 ` Al Viro 2015-09-14 14:19 ` Jeff Layton 2015-09-14 16:39 ` Al Viro 2015-09-14 17:30 ` Jeff Layton 2015-09-14 13:45 ` [PATCH 4/4] fs: export flush_delayed_fput Jeff Layton 2015-09-14 14:48 ` [PATCH 0/4] fs: allow userland tasks to use delayed_fput infrastructure J. Bruce Fields 2015-09-14 14:48 ` J. Bruce Fields 2015-09-14 15:21 ` Jeff Layton 2015-09-14 15:21 ` Jeff Layton
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1442238355-8203-1-git-send-email-jeff.layton@primarydata.com \ --to=jlayton@poochiereds.net \ --cc=bfields@fieldses.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-nfs@vger.kernel.org \ --cc=viro@ZenIV.linux.org.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.