From: bfields@fieldses.org (J. Bruce Fields)
To: "J. Bruce Fields" <bfields@redhat.com>
Cc: Jeff Layton <jlayton@redhat.com>,
linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org,
Trond Myklebust <trondmy@hammerspace.com>,
David Howells <dhowells@redhat.com>, Tejun Heo <tj@kernel.org>,
Peter Zijlstra <peterz@infradead.org>, Shaohua Li <shli@fb.com>,
Oleg Nesterov <oleg@redhat.com>
Subject: Re: [PATCH 0/7] Eliminate delegation self-conflicts
Date: Fri, 15 Feb 2019 11:35:14 -0500 [thread overview]
Message-ID: <20190215163514.GA22354@fieldses.org> (raw)
In-Reply-To: <20190211155803.GA28714@parsley.fieldses.org>
On Mon, Feb 11, 2019 at 10:58:04AM -0500, J. Bruce Fields wrote:
> On Sat, Feb 09, 2019 at 07:43:54AM -0500, Jeff Layton wrote:
> > On Fri, 2019-02-08 at 15:10 -0500, J. Bruce Fields wrote:
> > > From: "J. Bruce Fields" <bfields@redhat.com>
> > >
> > > These patches allow NFSv4 clients holding delegations to keep them when
> > > the operation that would break a delegation comes from the same client.
> > >
> > > To do that, we somehow need to pass the identity of the
> > > delegation-breaker down through the VFS.
> > >
> > > This series uses the tgid, a solution suggested by Trond. To do that we
> > > need nfsd tasks to share the same tgid. I do that by extending the
> > > kthread code slightly to allow knfsd to run the kthreadd main loop in a
> > > task of its own, and spawn its server threads off of that task.
> ...
> > Nice work! I like the basic idea, the changes seem to be well-organized,
> > and the tgid semantics are clear and make sense.
> >
> > Would this preclude us from moving to a workqueue-based model for knfsd
> > later? It's likely to still be worth it, but it'd be good to understand
> > the potential drawbacks.
>
> I was wondering about that too, but I haven't looked into it yet.
> Workqueues look a lot more complicated than kthreads.
I spent some time staring, and... I still don't really understand the
workqueue code. But if this kthread_group[*] code is acceptable than I
can't see why it shouldn't be possible to create a workqueue whose work
items are all handled by threads spawned form the same kthread_group.
--b.
[*] Open to suggestions of better names.
prev parent reply other threads:[~2019-02-15 16:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-08 20:10 [PATCH 0/7] Eliminate delegation self-conflicts J. Bruce Fields
2019-02-08 20:10 ` [PATCH 1/7] kthreads: minor kthreadd refactoring J. Bruce Fields
2019-02-08 20:10 ` [PATCH 2/7] kthreads: Simplify tsk_fork_get_node J. Bruce Fields
2019-02-08 20:10 ` [PATCH 3/7] kthreads: allow multiple kthreadd's J. Bruce Fields
2019-03-12 20:01 ` J. Bruce Fields
2019-02-08 20:10 ` [PATCH 4/7] kthreads: allow cloning threads with different flags J. Bruce Fields
2019-02-08 20:10 ` [PATCH 5/7] rpc: separate out body of svc_start_kthreads J. Bruce Fields
2019-02-08 20:10 ` [PATCH 6/7] rpc: move rpc server threads into their own thread group J. Bruce Fields
2019-02-08 20:10 ` [PATCH 7/7] nfsd: ignore delegation self-conflicts J. Bruce Fields
2019-02-09 12:43 ` [PATCH 0/7] Eliminate " Jeff Layton
2019-02-11 15:58 ` J. Bruce Fields
2019-02-15 16:35 ` J. Bruce Fields [this message]
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=20190215163514.GA22354@fieldses.org \
--to=bfields@fieldses.org \
--cc=bfields@redhat.com \
--cc=dhowells@redhat.com \
--cc=jlayton@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=shli@fb.com \
--cc=tj@kernel.org \
--cc=trondmy@hammerspace.com \
/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: link
Be 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.