----- Ursprüngliche Mail ----- > Von: "Johannes Berg" <johan...@sipsolutions.net> > An: "Benjamin Berg" <benja...@sipsolutions.net>, "Richard Weinberger" > <richard.weinber...@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
