linux-kernel - Re: [LKP] Re: [io_uring] 584b0180f0: phoronix-test-suite.fio.SequentialWrite.IO_uring.Yes.Yes.1MB.DefaultTestDirectory.mb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <26d913ea-7aa0-467d-4caf-a93f8ca5b3ff@kernel.dk>
Date:   Fri, 15 Jul 2022 09:58:24 -0600
From:   Jens Axboe <axboe@...nel.dk>
To:     Yin Fengwei <fengwei.yin@...el.com>,
        kernel test robot <oliver.sang@...el.com>
Cc:     LKML <linux-kernel@...r.kernel.org>, io-uring@...r.kernel.org,
        lkp@...ts.01.org, lkp@...el.com
Subject: Re: [LKP] Re: [io_uring] 584b0180f0:
 phoronix-test-suite.fio.SequentialWrite.IO_uring.Yes.Yes.1MB.DefaultTestDirectory.mb_s
 -10.2% regression

On 7/12/22 2:06 AM, Yin Fengwei wrote:
> Hi Jens,
> 
> On 5/27/2022 9:50 PM, Jens Axboe wrote:
>> I'm a bit skeptical on this, but I'd like to try and run the test case.
>> Since it's just a fio test case, why can't I find it somewhere? Seems
>> very convoluted to have to setup lkp-tests just for this. Besides, I
>> tried, but it doesn't work on aarch64...
> Recheck this regression report. The regression could be reproduced if
> the following config file is used with fio (tag: fio-3.25) :
> 
> 	[global]
> 	rw=write
> 	ioengine=io_uring
> 	iodepth=64
> 	size=1g
> 	direct=1
> 	buffered=1
> 	startdelay=5
> 	force_async=4
> 	ramp_time=5
> 	runtime=20
> 	time_based
> 	clat_percentiles=0
> 	disable_lat=1
> 	disable_clat=1
> 	disable_slat=1
> 	filename=test_fiofile
> 	[test]
> 	name=test
> 	bs=1M
> 	stonewall
> 
> Just FYI, a small change to commit: 584b0180f0f4d67d7145950fe68c625f06c88b10:
> 
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index 969f65de9972..616d857f8fc6 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -3181,8 +3181,13 @@ static int io_prep_rw(struct io_kiocb *req, const struct io_uring_sqe *sqe)
>  {
>         struct kiocb *kiocb = &req->rw.kiocb;
>         unsigned ioprio;
> +       struct file *file = req->file;
>         int ret;
> 
> +       if (likely(file && (file->f_mode & FMODE_WRITE)))
> +               if (!io_req_ffs_set(req))
> +                       req->flags |= io_file_get_flags(file) << REQ_F_SUPPORT_NOWAIT_BIT;
> +
>         kiocb->ki_pos = READ_ONCE(sqe->off);
> 
>         ioprio = READ_ONCE(sqe->ioprio);
> 
> could make regression gone. No idea how req->flags impact the write
> performance. Thanks.

I can't really explain that either, at least not immediately. I tried
running with and without that patch, and don't see any difference here.
In terms of making this more obvious, does the below also fix it for
you?

And what filesystem is this being run on?


diff --git a/fs/io_uring.c b/fs/io_uring.c
index a01ea49f3017..797fad99780d 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -4269,9 +4269,6 @@ static int io_rw_init_file(struct io_kiocb *req, fmode_t mode)
 	if (unlikely(!file || !(file->f_mode & mode)))
 		return -EBADF;
 
-	if (!io_req_ffs_set(req))
-		req->flags |= io_file_get_flags(file) << REQ_F_SUPPORT_NOWAIT_BIT;
-
 	kiocb->ki_flags = iocb_flags(file);
 	ret = kiocb_set_rw_flags(kiocb, req->rw.flags);
 	if (unlikely(ret))
@@ -8309,7 +8306,13 @@ static bool io_assign_file(struct io_kiocb *req, unsigned int issue_flags)
 	else
 		req->file = io_file_get_normal(req, req->cqe.fd);
 
-	return !!req->file;
+	if (unlikely(!req->file))
+		return false;
+
+	if (!io_req_ffs_set(req))
+		req->flags |= io_file_get_flags(file) << REQ_F_SUPPORT_NOWAIT_BIT;
+
+	return true;
 }
 
 static int io_issue_sqe(struct io_kiocb *req, unsigned int issue_flags)

-- 
Jens Axboe