On 22/02/18 12:35, Roger Pau Monné wrote:
> On Thu, Feb 22, 2018 at 11:16:53AM +0000, Ian Jackson wrote:
>> Jim Fehlig writes ("[PATCH] xenstore: increase default thread stack size to 
>> 32k"):
>>> On several Skylake machines I've observed xl segfaults when running
>>> create or destroy subcommands. Other subcommands may segfault too,
>>> but I've only looked at create and destroy which share a similar
>>> backtrace
>> Acked-by: Ian Jackson <ian.jack...@eu.citrix.com>
>> However, I am concerned that this isn't a very systematic way of
>> addressing this problem.  How do we know that 32K is enough ?
>> We have already increased this number once.
>> Alternatively, maybe this ia a bug in the platform libc ?
> Is it really that bad to use the default thread stack size? That's
> going to be much bigger, I know, but I assume physical memory for the
> stack will be mapped on demand, and thus the physical memory usage is
> not going to be that different.
> I've been always told to simply not play with the stack size.

Virtual memory isn't unlimited, especially in 32 bit programs.

It is possible to do a hack for obtaining the _free_ stack space in a
thread, even if it isn't really beautiful and relying on a non-standard
GNU extension (pthread_getattr_np()). It would require creating a test
thread looking how much space is left on the stack and size the watch's
thread stack accordingly.


Xen-devel mailing list

Reply via email to