[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] xenstore: increase default thread stack size to 32k

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.jackson@xxxxxxxxxxxxx>
>> 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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.