netdev - Re: [PATCH RFC v3 0/2] Task local data API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aBUQpPFemrUYxyO6@slm.duckdns.org>
Date: Fri, 2 May 2025 08:36:20 -1000
From: Tejun Heo <tj@...nel.org>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: Amery Hung <ameryhung@...il.com>, bpf@...r.kernel.org,
	netdev@...r.kernel.org, alexei.starovoitov@...il.com,
	andrii@...nel.org, daniel@...earbox.net, martin.lau@...nel.org,
	kernel-team@...a.com
Subject: Re: [PATCH RFC v3 0/2] Task local data API

Hello,

On Fri, May 02, 2025 at 09:14:47AM -0700, Andrii Nakryiko wrote:
> > The advantage of no memory wasted for threads that are not using TLD
> > doesn't seem to be that definite to me. If users add per-process
> > hints, then this scheme can potentially use a lot more memory (i.e.,
> > PAGE_SIZE * number of threads). Maybe we need another uptr for
> > per-process data? Or do you think this is out of the scope of TLD and
> > we should recommend other solutions?
> 
> I'd keep it simple. One page per thread isn't a big deal at all, in my
> mind. If the application has a few threads, then a bunch of kilobytes
> is not a big deal. If the application has thousands of threads, then a
> few megabytes for this is the least of that application's concern,
> it's already heavy-weight as hell. I think we are overpivoting on
> saving a few bytes here.

It could well be that 4k is a price worth paying but there will be cases
where this matters. With 100k threads - not common but not unheard of
either, that's ~400MB. If the data needed to be shared is small and most of
that is wasted, that's not an insignificant amount. uptr supports sub-page
sizing, right? If keeping sizing dynamic is too complex, can't a process
just set the max size to what it deems appropriate?

Thanks.

-- 
tejun