04:54:28 True, also I was only (hyper?)focussing on the ld.so.1 use of XSAVE, I need to make sure all cases are covered. 04:55:03 Also, maybe ld.so.1 needs to only reserve the size for its use, not whatever the CPU reports as "Maximum"? 04:56:10 apps were SEGV-ing on Sapphire rapids because it lowered stack by 11009/0x2a00 and it crossed out of the allocated mmap space. 15:01:28 Catching up a bit a few notes. First, sommerfeld is right that we aren't supposed to be using the maximum size here. Just the size for the configured features. 15:01:59 This isn't really a MAX or MIN thing. It needs to be kind of redone in general. 15:03:11 Regarding signal stacks with AMX, yes the classical defaults here are too small. https://github.com/illumos/ipd/blob/master/ipd/0038/README.adoc has two sections dedicated to this problem. https://github.com/illumos/ipd/blob/master/ipd/0038/README.adoc#signals-in-the-dark describes the problem. https://github.com/illumos/ipd/blob/master/ipd/0038/README.adoc#signal-stack-sizing is the solution. 15:03:36 However, until we actually add support for AMX or something else in there, we don't need to do the latter yet, though strictly speaking stuff could be at the periphery. 15:04:33 AMX makes this challenging and on other systems because of it it was being something that the application had to request to be enabled. So it's something that I would prefer to punt on until we make sure we understand the end-to-end enablement of AMX. 15:08:01 In general the reason this isn't a min/max is that there are other features that are saved in this. So it really has to be based on what we've specifically enabled. 15:10:16 And then there is a bit of a userland portion here where the layout of what's enabled and the combination of the operation that we're using impacts things. So right now we only use xsave. We don't need it for here, but at some point we may need to use xsavec so we can deal with large gaps not being used. 15:10:40 Is there an issue for this already? If so I can put an analysis somewhere.