Re: [PATCH v3 04/11] um: Don't use vfprintf() for os_info()

[Richard Weinberger <richard@nod.at>]

----- Ursprüngliche Mail -----
> Von: "Johannes Berg" <johannes@sipsolutions.net>
> An: "Benjamin Berg" <benjamin@sipsolutions.net>, "Richard Weinberger" <richard.weinberger@gmail.com>
> CC: "linux-um" <linux-um@lists.infradead.org>
> Gesendet: Freitag, 5. Januar 2024 09:56:11
> Betreff: Re: [PATCH v3 04/11] um: Don't use vfprintf() for os_info()

> On Fri, 2024-01-05 at 09:12 +0100, Benjamin Berg wrote:
>> > Another option is giving the helper threads more memory, we don't have
>> > that many.
>> > Did you explore this option already?
>> 
>> I had not really considered that.
>> 
>> One thing though is that userspace_tramp calls os_info while working
>> with the stub stack. So that also means setting STUB_DATA_PAGES to 2.
>> But, I suspect we may want to do that anyway eventually to fit the ever
>> increasing mcontext size for all the AVX512 registers and such.
> 
> That'll probably happen eventually regardless ...
> 
>> As I said, I think that is fine to do.
> 
> But I'm not sure it's a good solution to give more stack space to the
> threads and think/hope that glibc won't make more assumptions about the
> amount of space it can use ... who knows if it uses alloca() inside
> somewhere, for example? After all, userspace stacks are multiple
> megabytes by default?

For thread stacks things are a bit different.

glibc is in general more heap than stack greedy, it uses malloc() almost everywhere.
For pthreads the minimal stack size on x86 is 16k (_SC_THREAD_STACK_MIN).
Donating four pages to each helper thread seems okay to me.
And if I understand _SC_THREAD_STACK_MIN correctly, this is the minimal stack
size the glibc library can deal with.

Thanks,
//richard