Re: [RFC 0/6] fast poll multishot mode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



在 2021/9/3 下午7:00, Hao Xu 写道:
Let multishot support multishot mode, currently only add accept as its

              ^ fast poll
first comsumer.
theoretical analysis:
   1) when connections come in fast
     - singleshot:
               add accept sqe(userpsace) --> accept inline
                               ^                 |
                               |-----------------|
     - multishot:
              add accept sqe(userspace) --> accept inline
                                               ^     |
                                               |--*--|

     we do accept repeatedly in * place until get EAGAIN

   2) when connections come in at a low pressure
     similar thing like 1), we reduce a lot of userspace-kernel context
     switch and useless vfs_poll()


tests:
Did some tests, which goes in this way:

   server    client(multiple)
   accept    connect
   read      write
   write     read
   close     close

Basically, raise up a number of clients(on same machine with server) to
connect to the server, and then write some data to it, the server will
write those data back to the client after it receives them, and then
close the connection after write return. Then the client will read the
data and then close the connection. Here I test 10000 clients connect
one server, data size 128 bytes. And each client has a go routine for
it, so they come to the server in short time.
test 20 times before/after this patchset, time spent:(unit cycle, which
is the return value of clock())
before:
   1930136+1940725+1907981+1947601+1923812+1928226+1911087+1905897+1941075
   +1934374+1906614+1912504+1949110+1908790+1909951+1941672+1969525+1934984
   +1934226+1914385)/20.0 = 1927633.75
after:
   1858905+1917104+1895455+1963963+1892706+1889208+1874175+1904753+1874112
   +1874985+1882706+1884642+1864694+1906508+1916150+1924250+1869060+1889506
   +1871324+1940803)/20.0 = 1894750.45

(1927633.75 - 1894750.45) / 1927633.75 = 1.65%

Higher pressure like 10^5 connections causes problems since ports are
in use.
I'll test the cancellation path and try to lift pressure to much high
level to see if numbers get better. Sent this early for comments and
suggestions.

Hao Xu (6):
   io_uring: enhance flush completion logic
   io_uring: add IORING_ACCEPT_MULTISHOT for accept
   io_uring: add REQ_F_APOLL_MULTISHOT for requests
   io_uring: let fast poll support multishot
   io_uring: implement multishot mode for accept
   io_uring: enable multishot mode for accept

  fs/io_uring.c                 | 72 +++++++++++++++++++++++++++++------
  include/uapi/linux/io_uring.h |  4 ++
  2 files changed, 64 insertions(+), 12 deletions(-)





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux