From 57ab9b3dc98470983c1a6698af0e6ed022c31d1b Mon Sep 17 00:00:00 2001 From: Mark Johnston Date: Mon, 1 Jul 2024 11:40:32 -0400 Subject: [PATCH] sort: Avoid linear realloc loops These interact quite poorly with MRS with revocation enabled, which implements realloc() by always creating a new allocation. Even a modification to return the original pointer if its bounds satisfy the request doesn't help much there. Apply a simple bandaid: grow the allocation exponentially. This has no major downside except when virtual address space is scarce, and that's something we don't typically worry about. There doesn't appear to be any explicit justification for growing buffers so conservatively. --- usr.bin/sort/file.c | 2 +- usr.bin/sort/radixsort.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/usr.bin/sort/file.c b/usr.bin/sort/file.c index 339c9b8de270..4e6f2a7bf5aa 100644 --- a/usr.bin/sort/file.c +++ b/usr.bin/sort/file.c @@ -297,7 +297,7 @@ sort_list_add(struct sort_list *l, struct bwstring *str) size_t indx = l->count; if ((l->list == NULL) || (indx >= l->size)) { - size_t newsize = (l->size + 1) + 1024; + size_t newsize = (l->size + 1) * 2; l->list = sort_realloc(l->list, sizeof(struct sort_list_item*) * newsize); diff --git a/usr.bin/sort/radixsort.c b/usr.bin/sort/radixsort.c index 5ee998500d30..9940edb8c93a 100644 --- a/usr.bin/sort/radixsort.c +++ b/usr.bin/sort/radixsort.c @@ -232,7 +232,7 @@ add_to_sublevel(struct sort_level *sl, struct sort_list_item *item, size_t indx) } if (++(ssl->tosort_num) > ssl->tosort_sz) { - ssl->tosort_sz = ssl->tosort_num + 128; + ssl->tosort_sz = ssl->tosort_num * 2; ssl->tosort = sort_realloc(ssl->tosort, sizeof(struct sort_list_item*) * (ssl->tosort_sz)); } @@ -245,7 +245,7 @@ add_leaf(struct sort_level *sl, struct sort_list_item *item) { if (++(sl->leaves_num) > sl->leaves_sz) { - sl->leaves_sz = sl->leaves_num + 128; + sl->leaves_sz = sl->leaves_num * 2; sl->leaves = sort_realloc(sl->leaves, (sizeof(struct sort_list_item*) * (sl->leaves_sz))); }