Messages in this thread | | | Subject | Re: [PATCH] /dev/zero: also implement ->read | From | Christophe Leroy <> | Date | Mon, 7 Sep 2020 06:44:24 +0200 |
| |
Le 06/09/2020 à 22:52, David Laight a écrit : > From: Christophe Leroy >> Sent: 06 September 2020 19:36 >> Hi, >> >> Le 06/09/2020 à 20:21, Pavel Machek a écrit : >>> Hi! >>> >>>>>> Christophe reported a major speedup due to avoiding the iov_iter >>>>>> overhead, so just add this trivial function. Note that /dev/zero >>>>>> already implements both an iter and non-iter writes so this just >>>>>> makes it more symmetric. >>>>>> >>>>>> Christophe Leroy <christophe.leroy@csgroup.eu> >>>>>> Signed-off-by: Christoph Hellwig <hch@lst.de> >>>>> >>>>> Tested-by: Christophe Leroy <christophe.leroy@csgroup.eu> >>>> >>>> Any idea what has happened to make the 'iter' version so bad? >>> >>> Exactly. Also it would be nice to note how the speedup was measured >>> and what the speedup is. >>> >> >> Was measured on an 8xx powerpc running at 132MHz with: >> >> dd if=/dev/zero of=/dev/null count=1M >> >> With the patch, dd displays a throughput of 113.5MB/s >> Without the patch it is 99.9MB/s > > That in itself isn't a problem. > What was the throughput before any of these patches? > > I just remember another thread about the same test running > a lot slower after one of the related changes.
> While this speeds up read /dev/zero (which is uncommon) > if this is needed to get near the old performance then > the changes to the 'iter' code will affect real workloads.
If you are talking about the tests around the set_fs series from Christoph, I identified that the degradation was linked to CONFIG_STACKPROTECTOR_STRONG being selected by default, which provides unreliable results from one patch to another, GCC doing some strange things linked to unrelated changes.
With CONFIG_STACKPROTECTOR set to N, I get stable performance and no degradation with any of the patches of the set_fs series.
Christophe
| |