From: Jeff Layton <jeff.layton@primarydata.com>
To: "David Härdeman" <david@hardeman.nu>
Cc: Jeff Layton <jeff.layton@primarydata.com>,
linux-nfs@vger.kernel.org, SteveD@redhat.com
Subject: Re: [PATCH 00/19] gssd improvements
Date: Tue, 9 Dec 2014 09:58:13 -0500 [thread overview]
Message-ID: <20141209095813.163ac2bb@tlielax.poochiereds.net> (raw)
In-Reply-To: <4639bc17bcb236c23cfaf2bc57d98b67@hardeman.nu>
On Tue, 09 Dec 2014 14:52:56 +0100
David Härdeman <david@hardeman.nu> wrote:
> On 2014-12-09 14:09, Jeff Layton wrote:
> > On Tue, 09 Dec 2014 06:40:40 +0100
> > David Härdeman <david@hardeman.nu> wrote:
> >
> >> The following series converts gssd to use libevent and inotify instead
> >> of a handrolled event loop and dnotify. Lots of cleanups in the
> >> process
> >> (e.g. removing a lot of arbitrary limitations and fixed size buffers).
> ...
> >
> > Looks like a nice cleanup at first glance, but I haven't gone over it
> > in detail.
> >
> > One thing that _would_ be nice while you're in here though would be to
> > help parallelize more of process_krb5_upcall. Currently it forks before
> > changing its identity and then the parent waits on that to exit which
> > keeps everything serialized.
> >
> > I did it that way so that we didn't need change how we close the fds
> > afterward. Now that you're already doing some surgery there, that might
> > be easier to do and may help performance.
>
> Thanks, the current patchset doesn't really touch upon that code. After
> the patchset is applied, utils/gssd/gssd.c is basically everything that
> happens up to the point where data is available to read from the gss
> pipe but not after....
>
> But it should certainly make it easier to add parallelism in the
> future...
>
> BTW: when you say "how we close the fds"...what do you mean exactly?
>
>
> //David
Ahh, now I remember. It's not the closing of the fds that's the
problem, but you do need to have some way to reap the exit status from
the processes that are being forked off (so you don't end up with
zombies).
Probably not too hard to handle, but you would need to keep a count or
list of forked children and wait() on them at some point.
--
Jeff Layton <jlayton@primarydata.com>
next prev parent reply other threads:[~2014-12-09 14:58 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-09 5:40 [PATCH 00/19] gssd improvements David Härdeman
2014-12-09 5:40 ` [PATCH 01/19] nfs-utils: cleanup daemonization code David Härdeman
2014-12-09 5:40 ` [PATCH 02/19] nfs-utils: gssd - merge gssd_main_loop.c and gssd.c David Härdeman
2014-12-09 5:40 ` [PATCH 03/19] nfs-utils: gssd - simplify some option handling David Härdeman
2014-12-09 5:41 ` [PATCH 04/19] nfs-utils: gssd - remove arbitrary GSSD_MAX_CCACHE_SEARCH limitation David Härdeman
2014-12-09 5:41 ` [PATCH 05/19] nfs-utils: gssd - simplify topdirs path David Härdeman
2014-12-09 5:41 ` [PATCH 06/19] nfs-utils: gssd - move over pipfs scanning code David Härdeman
2014-12-09 5:41 ` [PATCH 07/19] nfs-utils: gssd - simplify client dir " David Härdeman
2014-12-09 5:41 ` [PATCH 08/19] nfs-utils: gssd - use libevent David Härdeman
2014-12-09 5:41 ` [PATCH 09/19] nfs-utils: gssd - remove "close me" code David Härdeman
2014-12-09 5:41 ` [PATCH 10/19] nfs-utils: gssd - make the client lists per-topdir David Härdeman
2014-12-09 5:41 ` [PATCH 11/19] nfs-utils: gssd - keep the rpc_pipefs dir open David Härdeman
2014-12-09 5:41 ` [PATCH 12/19] nfs-utils: gssd - use more relative paths David Härdeman
2014-12-09 5:41 ` [PATCH 13/19] nfs-utils: gssd - simplify topdir scanning David Härdeman
2014-12-09 5:41 ` [PATCH 14/19] nfs-utils: gssd - simplify client scanning David Härdeman
2014-12-09 5:41 ` [PATCH 15/19] nfs-utils: gssd - cleanup read_service_info David Härdeman
2014-12-09 5:42 ` [PATCH 16/19] nfs-utils: gssd - change dnotify to inotify David Härdeman
2014-12-09 5:42 ` [PATCH 17/19] nfs-utils: gssd - further shorten some pathnames David Härdeman
2014-12-09 5:42 ` [PATCH 18/19] nfs-utils: gssd - improve inotify David Härdeman
2014-12-09 5:42 ` [PATCH 19/19] nfs-utils: gssd - simplify handle_gssd_upcall David Härdeman
2014-12-09 13:09 ` [PATCH 00/19] gssd improvements Jeff Layton
2014-12-09 13:52 ` David Härdeman
2014-12-09 14:58 ` Jeff Layton [this message]
2014-12-09 15:07 ` Simo Sorce
2014-12-09 19:55 ` David Härdeman
2014-12-10 11:52 ` Jeff Layton
2014-12-10 14:08 ` David Härdeman
2014-12-10 14:17 ` Jeff Layton
2014-12-10 14:31 ` David Härdeman
2014-12-10 14:34 ` Jeff Layton
2014-12-10 16:03 ` David Howells
2014-12-10 19:03 ` Jeff Layton
2014-12-10 20:55 ` David Härdeman
2014-12-10 23:44 ` Ian Kent
2014-12-10 23:21 ` Benjamin Coddington
2014-12-11 0:12 ` Ian Kent
2014-12-11 1:54 ` Benjamin Coddington
2014-12-11 3:21 ` Ian Kent
2014-12-11 11:45 ` Jeff Layton
2014-12-11 12:55 ` Ian Kent
2014-12-11 13:46 ` Jeff Layton
2014-12-11 22:31 ` Ian Kent
2014-12-11 19:32 ` J. Bruce Fields
2014-12-11 19:50 ` Jeff Layton
2014-12-11 19:55 ` J. Bruce Fields
2014-12-11 20:11 ` Jeff Layton
2014-12-11 20:38 ` J. Bruce Fields
2014-12-11 22:20 ` Ian Kent
2014-12-09 16:39 ` Steve Dickson
2014-12-09 20:22 ` David Härdeman
2014-12-09 21:13 ` Steve Dickson
2014-12-10 14:20 ` David Härdeman
2014-12-10 20:35 ` J. Bruce Fields
2014-12-10 20:49 ` David Härdeman
2014-12-10 21:07 ` J. Bruce Fields
2015-01-28 21:29 ` Steve Dickson
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=20141209095813.163ac2bb@tlielax.poochiereds.net \
--to=jeff.layton@primarydata.com \
--cc=SteveD@redhat.com \
--cc=david@hardeman.nu \
--cc=linux-nfs@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox