From: Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>
To: Amery Hung <ameryhung@gmail.com>
Cc: bpf@vger.kernel.org, alexei.starovoitov@gmail.com,
andrii@kernel.org, daniel@iogearbox.net, eddyz87@gmail.com,
memxor@gmail.com, kernel-team@meta.com
Subject: Re: [PATCH bpf-next v1 2/3] selftests/bpf: Simplify task_local_data memory allocation
Date: Fri, 27 Mar 2026 21:15:07 +0000 [thread overview]
Message-ID: <87tsu1gejo.fsf@gmail.com> (raw)
In-Reply-To: <CAMB2axPBjQtdDog+ktgfgo3q=8NEke=Pq_LxD1ji0cD5ei80AA@mail.gmail.com>
Amery Hung <ameryhung@gmail.com> writes:
> On Fri, Mar 27, 2026 at 9:36 AM Mykyta Yatsenko
> <mykyta.yatsenko5@gmail.com> wrote:
>>
>> Amery Hung <ameryhung@gmail.com> writes:
>>
>> > Simplify data allocation by always using aligned_alloc() and passing
>> > size_pot, size rounded up to the closest power of two to alignment.
>> >
>> > Currently, aligned_alloc(page_size, size) is only intended to be used
>> > with memory allocators that can fulfill the request without rounding
>> > size up to page_size to conserve memory. This is enabled by defining
>> > TLD_DATA_USE_ALIGNED_ALLOC. The reason to align to page_size is due to
>> > the limitation of UPTR where only a page can be pinned to the kernel.
>> > Otherwise, malloc(size * 2) is used to allocate memory for data.
>> >
>> > However, we don't need to call aligned_alloc(page_size, size) to get
>> > a contiguous memory of size bytes within a page. aligned_alloc(size_pot,
>> > ...) will also do the trick. Therefore, just use aligned_alloc(size_pot,
>> > ...) universally.
>> >
>> > As for the size argument, create a new option,
>> > TLD_DONT_ROUND_UP_DATA_SIZE, to specify not rounding up the size.
>> > This preserves the current TLD_DATA_USE_ALIGNED_ALLOC behavior, allowing
>> > memory allocators with low overhead aligned_alloc() to not waste memory.
>> > To enable this, users need to make sure it is not an undefined behavior
>> > for the memory allocator to have size not being an integral multiple of
>> > alignment.
>> Why not simplify this further and just mmap() a page?
>>
>> data = mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE,
>> MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
>>
>> That gives you a page-aligned, page-sized buffer with no ambiguity
>> about alignment, page boundary crossings, or aligned_alloc() POSIX
>> compliance. munmap() on cleanup instead of free().
>>
>> The whole power-of-two rounding and TLD_DONT_ROUND_UP_DATA_SIZE
>> option adds complexity that's hard to justify for selftest
>> infrastructure. How does a user decide when to define/undefine
>> TLD_DONT_ROUND_UP? This is a selftest library -- the common case
>> should just work with the simplest possible approach
>
> This library, while residing in selftest, is designed to be used in
> production projects. sched_ext is in the process of adopting it.
> Therefore, simplicity is traded for efficiency.
>
> data here is allocated for every thread that calls tld_get_data(). So
> if we mmap a page for every thread (which could be in 100k order), it
> is going to waste a significant amount of memory.
>
Thanks for providing this context, it makes sense now.
>> >
>> > Compared to the current implementation, !TLD_DATA_USE_ALIGNED_ALLOC
>> > used to always waste size-byte of memory due to malloc(size * 2).
>> > Now the worst case becomes size - 1 and the best case is 0 when the size
>> > is already a power of two.
>> >
next prev parent reply other threads:[~2026-03-27 21:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-26 5:24 [PATCH bpf-next v1 0/3] Task local data bug fixes and improvement Amery Hung
2026-03-26 5:24 ` [PATCH bpf-next v1 1/3] selftests/bpf: Fix task_local_data data allocation size Amery Hung
2026-03-26 10:27 ` sun jian
2026-03-26 15:56 ` Amery Hung
2026-03-26 16:17 ` Mykyta Yatsenko
2026-03-26 20:32 ` Amery Hung
2026-03-26 5:24 ` [PATCH bpf-next v1 2/3] selftests/bpf: Simplify task_local_data memory allocation Amery Hung
2026-03-27 16:36 ` Mykyta Yatsenko
2026-03-27 20:56 ` Amery Hung
2026-03-27 21:15 ` Mykyta Yatsenko [this message]
2026-03-26 5:24 ` [PATCH bpf-next v1 3/3] selftests/bpf: Make sure TLD_DEFINE_KEY runs first Amery Hung
2026-03-27 16:56 ` Mykyta Yatsenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tsu1gejo.fsf@gmail.com \
--to=mykyta.yatsenko5@gmail.com \
--cc=alexei.starovoitov@gmail.com \
--cc=ameryhung@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=kernel-team@meta.com \
--cc=memxor@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.