| Message ID | 20221110155938.820334-1-miquel.raynal@bootlin.com |
|---|---|
| Headers | show |
| Series | Measure read while write latency | expand |
Applied to mtd-utils.git master. Thanks, David
On 21/11/22 08:37AM, David Oberhollenzer wrote: > Applied to mtd-utils.git master. But SPI NOR does not yet support read-while-write. The patches are still under review [0]. So does this even work? Should mtd-utils test a feature that has not been merged into the driver yet? I think it should not. [0] https://lore.kernel.org/linux-mtd/20221110155513.819798-1-miquel.raynal@bootlin.com/T/#mf4fdf32e77b1b21bd30ca01eed999f0efc3db6ee > > Thanks, > > David
Hi Pratyush, David pratyush@kernel.org wrote on Mon, 21 Nov 2022 10:40:20 +0100: > On 21/11/22 08:37AM, David Oberhollenzer wrote: > > Applied to mtd-utils.git master. > > But SPI NOR does not yet support read-while-write. The patches are still > under review [0]. So does this even work? Should mtd-utils test a > feature that has not been merged into the driver yet? I think it should > not. I don't mind if the tool gets in first, it won't hurt anyway as: - no changes are expected if people do not use the new -k option - if they do, the gained latency will just be 0 (which is a use case of the tool: measuring whether or not RWW works/is supported). > [0] https://lore.kernel.org/linux-mtd/20221110155513.819798-1-miquel.raynal@bootlin.com/T/#mf4fdf32e77b1b21bd30ca01eed999f0efc3db6ee The only thing is: if the series does not get in for any reason, we'll have to revert it. Either ways, I'm fine with it. Thanks, Miquèl
Macronix SPI-NOR flashes have Read-While-Write (RWW) capabilities. When programming/erasing big chunks of data, a subsequent read would take ages before being executed. If the area accessed by the read is not on the same bank of the program or erase, the read may just happen during the programming step (the bus being the bottleneck). Let's add a way to measure the latency gain with an additional flash_speed test. By providing '-b <x> -k <y> -c <z> --destructive', reads will be attempted on blocks [y; y+z] just after starting writes on blocks [x; x+z]. The test tool gives the total time of the operation (close to making a write then a read, serially) as well as the time when the read was over. If the device does not support the RWW feature, or if the reads and writes target the same bank, the read will end last at the end of the full operation. Otherwise, when the RWW feature is leveraged, the read ends much earlier. Example with a Macronix MX25UW51245G with bank and RWW support: // Testing the two accesses in the same bank $ flash_speed -b0 -k0 -c10 -d /dev/mtd0 [...] testing read while write latency read while write took 51ms, read ended after 51ms // Testing the two accesses within different banks $ flash_speed -b0 -k4096 -c10 -d /dev/mtd0 [...] testing read while write latency read while write took 51ms, read ended after 20ms Thanks, Miquèl Miquel Raynal (2): mtd-utils: flash_speed: Rework the time counting helpers mtd-utils: flash_speed: Measure read while write latency tests/mtd-tests/Makemodule.am | 5 +- tests/mtd-tests/flash_speed.c | 165 ++++++++++++++++++++++++++++++---- 2 files changed, 150 insertions(+), 20 deletions(-)