All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Dietrich <stettberger@dokucode.de>
To: Hao Xu <haoxu@linux.alibaba.com>, Jens Axboe <axboe@kernel.dk>
Cc: io-uring@vger.kernel.org, Joseph Qi <joseph.qi@linux.alibaba.com>,
	horst.schirmeier@tu-dresden.de,
	"Franz-B. Tuneke" <franz-bernhard.tuneke@tu-dortmund.de>,
	Hendrik Sieck <hendrik.sieck@tuhh.de>
Subject: Re: [POC RFC 0/3] support graph like dependent sqes
Date: Thu, 23 Dec 2021 11:06:17 +0100	[thread overview]
Message-ID: <s7by24bd49y.fsf@dokucode.de> (raw)
In-Reply-To: <20211214055734.61702-1-haoxu@linux.alibaba.com>

Hi everyone!

We experimented with the BPF patchset provided by Pavel a few months
ago. And I had the exact same question: How can we compare the benefits
and drawbacks of a more flexible io_uring implementation? In that
specific use case, I wanted to show that a flexible SQE-dependency
generation with BPF could outperform user-space SQE scheduling. From my
experience with BPF, I learned that it is quite hard to beat
io_uring+userspace, if there is enough parallelism in your IO jobs.

For this purpose, I've built a benchmark generator that is able to
produce random dependency graphs of various shapes (isolated nodes,
binary tree, parallel-dependency chains, random DAC) and different
scheduling backends (usual system-call backend, plain io_uring,
BPF-enhanced io_uring) and different workloads.

At this point, I didn't have the time to polish the generator and
publish it, but I put the current state into this git:

https://collaborating.tuhh.de/e-exk4/projects/syscall-graph-generator

After running:

    ./generate.sh
    [sudo modprobe null_blk...]
    ./run.sh
    ./analyze.py

You get the following results (at least if you own my machine):

generator              iouring      syscall      iouring_norm
graph action size
chain read   128    938.563366  2019.199010   46.48%
flat  read   128    922.132673  2011.566337   45.84%
graph read   128   1129.017822  2021.905941   55.84%
rope  read   128   2051.763366  2014.563366  101.85%
tree  read   128   1049.427723  2015.254455   52.07%

For the userspace scheduler, I perform an offline analysis that finds
linear chains of operations that are not (anymore) dependent on other previous
unfinished results. These linear chains are then pushed into io_uring
with a SQE-link chain.

As I'm highly interested in this topic of pushing complex
IO-dependencies into the kernel space, I would be delighted to see how
your SQE-graph extension would compare against my rudimentary userspace
scheduler.

@Hao: Do you have a specific use case for your graph-like dependencies
      in mind? If you need assistance with the generator, please feel
      free to contact me.

chris
-- 
Prof. Dr.-Ing. Christian Dietrich
Operating System Group (E-EXK4)
Technische Universität Hamburg
Am Schwarzenberg-Campus 3 (E), 4.092
21073 Hamburg

eMail:  christian.dietrich@tuhh.de
Tel:    +49 40 42878 2188
WWW:    https://osg.tuhh.de/

  parent reply	other threads:[~2021-12-23 10:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-14  5:57 [POC RFC 0/3] support graph like dependent sqes Hao Xu
2021-12-14  5:57 ` [PATCH 1/3] io_uring: add data structure for graph sqe feature Hao Xu
2021-12-14  5:57 ` [PATCH 2/3] io_uring: implement new sqe opcode to build graph like links Hao Xu
2021-12-14  5:57 ` [PATCH 3/3] io_uring: implement logic of IOSQE_GRAPH request Hao Xu
2021-12-14 15:21 ` [POC RFC 0/3] support graph like dependent sqes Pavel Begunkov
2021-12-14 16:53   ` Hao Xu
2021-12-14 18:16     ` Pavel Begunkov
2021-12-16 16:55       ` Hao Xu
2021-12-17 19:33         ` Pavel Begunkov
2021-12-18  6:57           ` Hao Xu
2021-12-21 16:19             ` Pavel Begunkov
2021-12-23  4:14               ` Hao Xu
2021-12-23 10:06 ` Christian Dietrich [this message]
2021-12-27  3:27   ` Hao Xu
2021-12-27  5:49     ` Christian Dietrich

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=s7by24bd49y.fsf@dokucode.de \
    --to=stettberger@dokucode.de \
    --cc=axboe@kernel.dk \
    --cc=franz-bernhard.tuneke@tu-dortmund.de \
    --cc=haoxu@linux.alibaba.com \
    --cc=hendrik.sieck@tuhh.de \
    --cc=horst.schirmeier@tu-dresden.de \
    --cc=io-uring@vger.kernel.org \
    --cc=joseph.qi@linux.alibaba.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.