Bug#722898: benchmarks
Hi Thiemo
Thanks for working on this.
Thiemo Nagel <thiemo.nagel@gmail.com> writes:
> Hello Ben,
>
> thanks for your input! I'm attaching a series of patches to wrap up what
> we've discussed so far, more details are in the commit messages quoted
> below.
>
> I've tested the patches by running blockdev-wipe, they are looking good. I
> haven't tried to build the installer with the new block-dev wipe, though,
> and therefore would appreciate further testing and/or code review.
>
> Even with the latest version of blockdev-wipe, I'm still seeing ~20%
> improvement by setting min_speed to zero. Yet, I'd suggest to hold back the
> speedlimit patch because I'd expect similar gains for the package
> installation phase. Thus I believe that it makes more sense to set
> speed_limit_min to zero during the startup of the debian installer. Could
> someone please advise me as to where that would fit in best?
The best place to enable this is probably partman-md after creating the
RAID device.
> #5 blockdev-wipe: Set blocksize to 512k
>
> This should be large enough to avoid excessive system call
> overhead and small enough to prevent problems on systems with
> very little RAM.
Any reason why you choose 512k? If I understand your benchmarks right,
doubling this to 1M yelds about another 27% gain. Does increasing the
buffer to 1M just increase the memory requirement by 512k or is there a
"hidden" penalty to it? If it's just 512k I don't think we should care
as d-i needs in the order of 70-100M overall. And if it turns out to be
a problem wiping could be disabled in lowmem situations.
>
> #4 blockdev-wipe: Sync at most once per second
>
> Don't open output devices with O_SYNC, instead sync manually
> every time the progress indicator is updated, but not more
> often than once per second. This yields performance gains
> of up to factor 10 in setups with dm-crypt on dm-raid.
>
> Note: Seven years ago, O_SYNC was added to fix OOM issues
> (cf. bug #381135), however it is believed that this problem
> has been addressed in the kernel by now.
>
> #3 blockdev-wipe: Allocate buffer from heap instead of stack
>
> This allows to use buffers larger than 8M, also it fails more
> gracefully in case the memory can't be allocated.
>
> #2 blockdev-wipe: Reduce progress indicator granularity to 1/1000
This still sounds like a lot of granularity. IMO this could be reduced
to 1/100. Do we really need progress updates for less than 1%?
Gaudenz
--
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~
Reply to: