On Sat, Jan 23, 2021 at 10:37:25AM -0700, Jens Axboe wrote:
> > IORING_OP_GETDENTS64 behaves like getdents64(2) and takes the same
> > arguments.
> >
> > Signed-off-by: Lennert Buytenhek <buyt...@wantstofly.org>
> > ---
> > This seems to work OK, but I'd appreciate a review from someone more
> > familiar with io_uring internals than I am, as I'm not entirely sure
> > I did everything quite right.
> >
> > A dumb test program for IORING_OP_GETDENTS64 is available here:
> >
> > https://krautbox.wantstofly.org/~buytenh/uringfind.c
> >
> > This does more or less what find(1) does: it scans recursively through
> > a directory tree and prints the names of all directories and files it
> > encounters along the way -- but then using io_uring. (The uring version
> > prints the names of encountered files and directories in an order that's
> > determined by SQE completion order, which is somewhat nondeterministic
> > and likely to differ between runs.)
> >
> > On a directory tree with 14-odd million files in it that's on a
> > six-drive (spinning disk) btrfs raid, find(1) takes:
> >
> > # echo 3 > /proc/sys/vm/drop_caches
> > # time find /mnt/repo > /dev/null
> >
> > real 24m7.815s
> > user 0m15.015s
> > sys 0m48.340s
> > #
> >
> > And the io_uring version takes:
> >
> > # echo 3 > /proc/sys/vm/drop_caches
> > # time ./uringfind /mnt/repo > /dev/null
> >
> > real 10m29.064s
> > user 0m4.347s
> > sys 0m1.677s
> > #
> >
> > These timings are repeatable and consistent to within a few seconds.
> >
> > (btrfs seems to be sending most metadata reads to the same drive in the
> > array during this test, even though this filesystem is using the raid1c4
> > profile for metadata, so I suspect that more drive-level parallelism can
> > be extracted with some btrfs tweaks.)
> >
> > The fully cached case also shows some speedup for the io_uring version:
> >
> > # time find /mnt/repo > /dev/null
> >
> > real 0m5.223s
> > user 0m1.926s
> > sys 0m3.268s
> > #
> >
> > vs:
> >
> > # time ./uringfind /mnt/repo > /dev/null
> >
> > real 0m3.604s
> > user 0m2.417s
> > sys 0m0.793s
> > #
> >
> > That said, the point of this patch isn't primarily to enable
> > lightning-fast find(1) or du(1), but more to complete the set of
> > filesystem I/O primitives available via io_uring, so that applications
> > can do all of their filesystem I/O using the same mechanism, without
> > having to manually punt some of their work out to worker threads -- and
> > indeed, an object storage backend server that I wrote a while ago can
> > run with a pure io_uring based event loop with this patch.
>
> The results look nice for sure.
Thanks! And thank you for having a look.
> Once concern is that io_uring generally
> guarantees that any state passed in is stable once submit is done. For
> the below implementation, that doesn't hold as the linux_dirent64 isn't
> used until later in the process. That means if you do:
>
> submit_getdents64(ring)
> {
> struct linux_dirent64 dent;
> struct io_uring_sqe *sqe;
>
> sqe = io_uring_get_sqe(ring);
> io_uring_prep_getdents64(sqe, ..., &dent);
> io_uring_submit(ring);
> }
>
> other_func(ring)
> {
> struct io_uring_cqe *cqe;
>
> submit_getdents64(ring);
> io_uring_wait_cqe(ring, &cqe);
>
> }
>
> then the kernel side might get garbage by the time the sqe is actually
> submitted. This is true because you don't use it inline, only from the
> out-of-line async context. Usually this is solved by having the prep
> side copy in the necessary state, eg see io_openat2_prep() for how we
> make filename and open_how stable by copying them into kernel memory.
> That ensures that if/when these operations need to go async and finish
> out-of-line, the contents are stable and there's no requirement for the
> application to keep them valid once submission is done.
>
> Not sure how best to solve that, since the vfs side relies heavily on
> linux_dirent64 being a user pointer...
No data is passed into the kernel on a getdents64(2) call via user
memory, i.e. getdents64(2) only ever writes into the supplied
linux_dirent64 user pointer, it never reads from it. The only things
that we need to keep stable here are the linux_dirent64 pointer itself
and the 'count' argument and those are both passed in via the SQE, and
we READ_ONCE() them from the SQE in the prep function. I think that's
probably the source of confusion here?
Cheers,
Lennert
