On Thu, 27 Nov 2025 at 17:58, Mark Rutland <[email protected]> wrote: > > On Thu, Nov 27, 2025 at 03:56:59PM +0000, Ryan Roberts wrote: > > On 27/11/2025 15:03, Ard Biesheuvel wrote: > > > So the question is really whether we want to dedicate 16 bytes per > > > task for this. I wouldn't mind personally, but it is something our > > > internal QA engineers tend to obsess over. > > > > Yeah that's a good point. > > I think it's a fair point that some people will obsesses over this, but > I think the concern is misplaced. > > I know that people were very happy for the kernel FPSIMD context to > disappear from task_struct, but 16 bytes is a fair amount smaller, and > I'm pretty sure we can offset that with a small/moderate amount of work. > > AFAICT there are extant holes in task_struct that could easily account > for 16 bytes. I can also see a few ways to rework arm64's thread_info > and thread_struct (which are both embedded within task_struct) to save > some space. >
Oh, I completely agree. But it is going to come up one way or the other. > > Is this something we could potentially keep at the start of the > > kstack? Is there any precident for keeping state there at the moment? > > For arm64, I know there is a general feeling that 16K for the stack > > more than enough (but we are stuck with it because 8K isn't quite > > enough). So it would be "for free". I guess it would be tricky to do > > this in an arch-agnostic way though... > > We went out of our way to stop playing silly games like that when we > moved thread_info into task_struct; please let's not bring that back. > Agreed. (after just having moved the kernel mode FP/SIMD buffer from task_struct to the kernel mode stack :-))
