Messages in this thread | | | From | <> | Subject | Re: [PATCH] mtd: revert "spi-nor: intel: provide a range for poll_timout" | Date | Tue, 28 Jul 2020 08:28:22 +0000 |
| |
Hi, Mika,
On 7/23/20 12:05 PM, Alexander Sverdlin wrote: > > Hello Tudor, > > On 22/07/2020 19:03, Tudor.Ambarus@microchip.com wrote: >> On 7/22/20 7:37 PM, Alexander Sverdlin wrote: > > [...] > >>> I've performed my testing as well and got the following results: >>> >>> Vanilla Linux 4.9 (i.e. before the introduction of the offending >>> patch): >>> >>> dd if=/dev/flash/by-name/XXX of=/dev/null bs=4k >>> 1280+0 records in >>> 1280+0 records out >>> 5242880 bytes (5.2 MB, 5.0 MiB) copied, 3.91981 s, 1.3 MB/s >>> >>> Vanilla 4.19 (i.e. with offending patch): >>> >>> dd if=/dev/flash/by-name/XXX of=/dev/null bs=4k >>> 1280+0 records in >>> 1280+0 records out >>> 5242880 bytes (5.2 MB, 5.0 MiB) copied, 6.70891 s, 781 kB/s >>> >>> 4.19 + revert: >>> >>> dd if=/dev/flash/by-name/XXX of=/dev/null bs=4k >>> 1280+0 records in >>> 1280+0 records out >>> 5242880 bytes (5.2 MB, 5.0 MiB) copied, 3.90503 s, 1.3 MB/s >>>
[cut]
> with 10us it looks like this: > > dd if=/dev/flash/by-name/... of=/dev/null bs=4k > 1280+0 records in > 1280+0 records out > 5242880 bytes (5.2 MB, 5.0 MiB) copied, 4.33816 s, 1.2 MB/s > > Which means, there is a performance regression and it would depend on > the test case, how bad it will be... >
We need a bit of a context here. Using a tight-loop for polling and having a 5 secs timeout is fishy. For anything that's expected to complete less than a few usec, it's usually better to poll continuously, but then a timeout of 5s is way too big. Can we shrink the timeout to few msecs?
I'll queue this to spi-nor/next to fix the perf regression, but I would like to continue the discussion and to come up with an incremental patch on top of this one.
Cheers, ta
| |