[LU-13799] DIO/AIO efficiency improvements

• Type: Bug
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.15.0
• Severity: 3
• Assignee: Patrick Farrell
• Reporter: Patrick Farrell

Description

There is a large degree of inefficiency/wasted time in the DIO/AIO path.  This does not show up for DIO normally because of the waiting model. but it shows up easily in AIO.

This ticket is to cover a set of improvements to DIO/AIO performance, which will also improve DIO performance once the waiting model is adjusted.  (More on this in LU-13798.)

There is a grab bag of patches to be submitted here, and some further proposals that will probably end up in other tickets.

The essence of the improvements is that all pages in a DIO submission are the same, and therefore much of the work done on a per-page basis is irrelevant and can be skipped for DIO.  Note this statement is still compatible with unaligned DIO if it can be implemented in the future - In the case of unaligned DIO, only the first and last pages are different, and that can still be handled.

Patches and benchmarks on each patch forthcoming.

The total effect of the initial set of patches on my testbed is to raise AIO/DIO performance from around 5 GiB/s to around 9 GiB/s.  I'll get more in to what else can be done shortly. 

Issue Links

• is related to: LU-13798 Improve direct i/o performance with multiple stripes: Submit all stripes of a DIO and then wait
• is related to: LU-13802 New i/o path: Buffered i/o as DIO
• is related to: LU-13805 i/o path: Unaligned direct i/o
• is related to: LU-13814 DIO performance: cl_page struct removal for DIO path
• is related to: LU-15483 Minor DIO test improvements
• is related to: LU-13801 Enable io_uring interface for Lustre client

Comments

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/39443/
Subject: LU-13799 llite: Move free user pages
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 7f9b8465bc1125e51aa29cdc27db9a9d6fdc0b89

[Gerrit Updater]

"Patrick Farrell <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/46139
Subject: LU-13799 tests: Use fallocate to fill OSTs
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 53aa72a20e7af4cdbfd825a8f35100d901266903

[Gerrit Updater]

"Patrick Farrell <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/46135
Subject: LU-13799 tests: Reduce I/O sizes
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 0bd3f71bdced8c80513199a6ffebed96a4d0fb54

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/44209/
Subject: LU-13799 llite: Implement lower/upper aio
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 46ff76137160b66f1d4437b3443859027faae9c4

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/44153/
Subject: LU-13799 osc: Always set aio in anchor
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: eadccb33ac4bbe54a01da5168f6170702f9b2629

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/44154/
Subject: LU-13799 llite: Simplify cda_no_aio_complete use
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: b60bd21ec5d5f34ed79c63158860b6f5e948dba2

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/39445/
Subject: LU-13799 lov: Cache stripe offset calculation
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 14db1faa0fbe813fed616435303753d390f45827

[Shuichi Ihara]

I'm just curious because it's possible some of these were limited by max_rpcs_in_flight.

Yeah, i also thought that helps, but didn't help very much. because it still doesn't reach to max_rpcs_in_flight limit somehow. see example.

# lctl set_param osc.*.rpc_stats=clear
# lfs setstripe -c 8 -S 1M /ai400x2/ior.out/
# mpirun -np 1 ior -w -r -t 256m -b 8G -o /ai400x2/ior.out/file --posix.odirect -e
# lctl get_param osc.*.rpc_stats
			read			write
pages per rpc         rpcs   % cum % |       rpcs   % cum %
1:		         0   0   0   |          0   0   0
2:		         0   0   0   |          0   0   0
4:		         0   0   0   |          0   0   0
8:		         0   0   0   |          0   0   0
16:		         0   0   0   |          0   0   0
32:		         0   0   0   |          0   0   0
64:		         0   0   0   |          0   0   0
128:		         0   0   0   |          0   0   0
256:		      1024 100 100   |       1024 100 100

			read			write
rpcs in flight        rpcs   % cum % |       rpcs   % cum %
1:		       142  13  13   |        856  83  83
2:		       873  85  99   |        152  14  98
3:		         5   0  99   |          9   0  99
4:		         2   0  99   |          6   0  99
5:		         1   0  99   |          1   0 100
6:		         1   0 100   |          0   0 100

98-99% of rpcs is still 2 rpcs in flight here.

[Patrick Farrell]

OK, I see in the spreadsheet you used:
https://review.whamcloud.com/#/c/44293/

That is missing:
https://review.whamcloud.com/#/c/39445/

Because I did not put it in the series.  If possible, you might want to retest with that patch added.

[Patrick Farrell]

sihara how many OSTs did you have in your system and how many stripes did you use?

lctl set_param osc..max_pages_per_rpc=16M osc..checksums=0 osc.*.max_rpcs_in_flight=16

 

I'm just curious because it's possible some of these were limited by max_rpcs_in_flight.

Still, that performance is excellent - significantly better than I expected.

[Patrick Farrell]

sihara:
https://review.whamcloud.com/#/c/44445/ is one of the EXA6 versions of these patches.  Did you mean to link a different one?