3

We can see some parameters by issuing "iostat -x -d", the rrqm/s and wrqm/s stand for the merge for I/O request per second. And there is a kernel parameter controlling the I/O merge:

/sys/class/block/device-name/queue/nomerges

According to the Kernel Doc:

This enables the user to disable the lookup logic involved with IO merging requests in the block layer. By default (0) all merges are enabled. When set to 1 only simple one-hit merges will be tried. When set to 2 no merge algorithms will be tried (including one-hit or more complex tree/hash lookups).

The meaning of 0 and 2 are easy to understand, but when it comes to 1 with "one-hit", I googled around, but no specific semantic definition towards it. So please help explain what exactly the meaning of 1 for nomerges is. Thanks.

Jepsenwan
  • 170
  • 3
  • 12

1 Answers1

5

0 does both a simple check for adjacent requests plus a look up in a data structure, 1 only does the simple check, and 2 does no merging. Have a look at the implementation, block/elevator.c in elv_merge().

You need to test your heavy random I/O workload to tell if it will benefit from disabling merging. The merge of option 2 showed throughput per CPU time improved a fraction of a percent with 2 versus 1: block: Added in stricter no merge semantics for block I/O

Even option 0 is quite cheap, and lots of requests are adjacent. You probably do not need to change this.

John Mahowald
  • 32,050
  • 2
  • 19
  • 34
  • Thanks. John. I think I got that the continuous requests will be merged. With the value set to 1, the complex merge checks are disabled, but simple one-shot merges with the previous I/O request are enabled. Could you figure what it means here by "complex merge" and "one-shot"? – Jepsenwan Jul 30 '17 at 07:32
  • Currently, 0 adds a hash lookup as documented. It spends a few CPU cycles on the chance an I/O can be merged. If you care to know more about the implementation, read block/elevator.c and block/blk-merge.c. – John Mahowald Jul 30 '17 at 15:59