[PATCH] malloc: Improve performance of __libc_calloc
DJ Delorie
dj@redhat.com
Tue May 13 18:31:09 GMT 2025
Wilco Dijkstra <Wilco.Dijkstra@arm.com> writes:
> Malloc doesn't build at all with a different INTERNAL_SIZE_T. But
> basically that would be an unchecked cast of size_t to a smaller
> INTERNAL_SIZE_T, thus incorrectly dealing with huge user allocations.
Hmm... I suspected that. I suppose out of fairness we should decide
"this is the way" and remove it all, but at a minimum we could just
assert it's the same as size_t. Not worried about it now though.
> See v2 below - I also fixed another oddity: a signed ptrdiff_t was
> used in the overflow check. Using size_t makes more sense since
> checked_request2size deals with huge sizes.
Applies cleanly, thanks.
> On Neoverse V2, bench-calloc-simple improves by 5.0%
> overall. Bench-calloc-tcache 32 improves by 24%.
I noted Cupertino's comment on the benchmark name ;-)
> Regress passed, OK for commit?
LGTM
Reviewed-by: DJ Delorie <dj@redhat.com>
FYI patchwork's code sees the "Re: " and assume's it's a reply to an
existing patch; to trigger a v2 in patchwork you need to remove the Re:
part (at least) and preferably add the [PATCH v2] in the $subject.
Then, in patchwork, you can mark the v1 patch as superceeded and the v2
as accepted. I go a step further and split my reply to comments and
updated patch into separate emails, so that the patch emails are closer
to what's in git.
Most of the above paragraph is nit-picking, except the part where you
have to remove the Re: if you want patchwork to detect the new patch ;-)
More information about the Libc-alpha
mailing list