All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kurz <groug@kaod.org>
To: Christian Schoenebeck <qemu_oss@crudebyte.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [PATCH v6 4/5] 9pfs: T_readdir latency optimization
Date: Mon, 29 Jun 2020 18:39:02 +0200	[thread overview]
Message-ID: <20200629183902.75d6fb0b@bahia.lan> (raw)
In-Reply-To: <3959658.0YslYoXCm0@silver>

On Wed, 03 Jun 2020 19:16:08 +0200
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:

> On Sonntag, 19. April 2020 17:06:17 CEST Christian Schoenebeck wrote:
> > Make top half really top half and bottom half really bottom half:
> > 
> > Each T_readdir request handling is hopping between threads (main
> > I/O thread and background I/O driver threads) several times for
> > every individual directory entry, which sums up to huge latencies
> > for handling just a single T_readdir request.
> > 
> > Instead of doing that, collect now all required directory entries
> > (including all potentially required stat buffers for each entry) in
> > one rush on a background I/O thread from fs driver by calling the
> > previously added function v9fs_co_readdir_many() instead of
> > v9fs_co_readdir(), then assemble the entire resulting network
> > response message for the readdir request on main I/O thread. The
> > fs driver is still aborting the directory entry retrieval loop
> > (on the background I/O thread inside of v9fs_co_readdir_many())
> > as soon as it would exceed the client's requested maximum R_readdir
> > response size. So this will not introduce a performance penalty on
> > another end.
> > 
> > Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
> > ---
> >  hw/9pfs/9p.c | 122 +++++++++++++++++++++++----------------------------
> >  1 file changed, 55 insertions(+), 67 deletions(-)
> 
> Ping. Anybody?
> 
> I would like to roll out this patch set soon and this is the only patch in 
> this series missing a review yet.
> 

Hi Christian,

Sorry for getting back to this only now :-\

So I still have some concerns about the locking of the directory stream
pointer a fid. It was initially introduced to avoid concurrent accesses
by multiple threads to the corresponding internal glibc object, as
recommended in the readdir(3) manual page. Now, this patch considerably
extends the critical section to also contain calls to telldir() and all
the _many_ readdir()... so I'm not sure exactly what's the purpose of
that mutex right now. Please provide more details.

Cheers,

--
Greg


  reply	other threads:[~2020-06-29 16:39 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-19 15:10 [PATCH v6 0/5] 9pfs: readdir optimization Christian Schoenebeck
2020-04-19 15:00 ` [PATCH v6 1/5] tests/virtio-9p: added split readdir tests Christian Schoenebeck
2020-04-19 15:00 ` [PATCH v6 2/5] 9pfs: make v9fs_readdir_response_size() public Christian Schoenebeck
2020-04-19 15:02 ` [PATCH v6 3/5] 9pfs: add new function v9fs_co_readdir_many() Christian Schoenebeck
2020-04-30 11:42   ` Greg Kurz
2020-04-30 12:50     ` Christian Schoenebeck
2020-04-30 13:30       ` Greg Kurz
2020-05-01 14:04         ` Christian Schoenebeck
2020-05-04  9:18           ` Greg Kurz
2020-05-04 10:08             ` Christian Schoenebeck
2020-05-07 12:16             ` Christian Schoenebeck
2020-05-07 15:59               ` Greg Kurz
2020-04-19 15:06 ` [PATCH v6 4/5] 9pfs: T_readdir latency optimization Christian Schoenebeck
2020-06-03 17:16   ` Christian Schoenebeck
2020-06-29 16:39     ` Greg Kurz [this message]
2020-06-30 15:16       ` Christian Schoenebeck
2020-06-30 16:39         ` Greg Kurz
2020-06-30 18:00           ` Christian Schoenebeck
2020-07-01 10:09             ` Greg Kurz
2020-07-01 11:47               ` Christian Schoenebeck
2020-07-01 15:12                 ` Greg Kurz
2020-07-02 11:43                   ` Christian Schoenebeck
2020-07-02 15:35                     ` Greg Kurz
2020-07-02 17:23                       ` Christian Schoenebeck
2020-07-03  8:08                         ` Christian Schoenebeck
2020-07-03 16:08                           ` Greg Kurz
2020-07-03 18:27                             ` Christian Schoenebeck
2020-07-03 15:53                         ` Greg Kurz
2020-07-03 18:12                           ` Christian Schoenebeck
2020-04-19 15:07 ` [PATCH v6 5/5] 9pfs: clarify latency of v9fs_co_run_in_worker() Christian Schoenebeck

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=20200629183902.75d6fb0b@bahia.lan \
    --to=groug@kaod.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu_oss@crudebyte.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.