Hi Thiemo Thanks for working on this.
Thiemo Nagel <[email protected]> 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 ~ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
