[PATCH v1 0/6] Fast restart with many hugepages
Bruce Richardson
bruce.richardson at intel.com
Thu Jan 20 10:05:59 CET 2022
On Wed, Jan 19, 2022 at 09:12:27PM +0000, Dmitry Kozlyuk wrote:
> Hi Bruce,
>
> > From: Bruce Richardson <bruce.richardson at intel.com>
> > [...]
> > this seems really interesting, but in the absense of TB of memory
> > being
> > used, is it easily possible to see the benefits of this work? I've
> > been
> > playing with adding large memory allocations to helloworld example and
> > checking the runtime. Allocating 1GB using malloc per thread seems to
> > show
> > a small (<0.5 second at most) benefit, and using a fixed 10GB
> > allocation
> > using memzone_reserve at startup shows runtimes within the margin of
> > error
> > when run with --huge-unlink=existing vs huge-unlink=never. At what
> > size of
> > memory footprint is it expected to make a clear improvement?
>
> Sorry, there was a bug in v1 that completely broke the testing.
> I should've double-checked
> after what I considered a quick rebase before sending.
> Version 2 can be simply tested even without modifyin the code:
>
> time sh -c 'echo quit | sudo ../_build/dpdk/app/test/dpdk-test
> --huge-unlink=never -m 8192 --single-file-segments --no-pci
> 2>/dev/null >/dev/null'
>
> With --huge-unlink=existing:
> real 0m1.450s
> user 0m0.574s
> sys 0m0.706s (1)
>
> With --huge-unlink=never, first run (no hugepage files to reuse):
> real 0m0.892s
> user 0m0.002s
> sys 0m0.718s (2)
>
> With --huge-unlink=never, second run (hugepage files left):
> real 0m0.210s
> user 0m0.010s
> sys 0m0.021s (3)
>
> Notice that (1) and (2) are close since there is no reuse,
> but (2) and (3) are differ by 0.7 seconds for 8GB,
> which correlates with 14 GB/sec memset() speed on this machine.
> Results without --single-file-segments are nearly identical.
Thanks, glad to hear it wasn't just me! I'll check again the v2 when I get
the chance.
More information about the dev
mailing list