On Thu, 2024-07-11 at 15:30 -0700, Dave Hansen wrote: > > > $BYTES is 24, right? Did I get anything wrong? > > > > Do we know what the actual memory use is? It would increases the size asked > > of > > of the allocator by 24 bytes, but what amount of memory actually gets > > reserved? > > > > It is sometimes a slab allocated buffer, and sometimes a vmalloc, right? I'm > > not > > sure about slab sizes, but for vmalloc if the increase doesn't cross a page > > size, it will be the same size allocation in reality. Or if it is close to a > > page size already, it might use a whole extra 4096 bytes. > > Man, I hope I don't have this all mixed up in my head. Wouldn't be the > first time. I _think_ you might be confusing thread_info and > thread_struct, though. I know I've gotten them confused before. > > But we get to the 'struct fpu' via: > > current->thread.fpu > > Where current is a 'task_struct' which is in /proc/slabinfo and 'struct > thread_struct thread' and 'struct fpu' are embedded in 'task_struct', > not allocated on their own: I think thread_struct is always a slab, but the current->thread.fpu.fpstate pointer can be reallocated to point to a vmalloc in fpstate_realloc(), in the case of XFD features. > > task_struct 2958 3018 10048 3 8 ... > > So my current task_struct is 10048 bytes and 3 of them fit in each > 8-page slab, leaving 2624 bytes to spare. > > I don't think we're too dainty about adding thing to task_struct. Are we? So for you there would actually not be any extra memory usage to unconditionally add 24 bytes to the xstate. But, yes, it all could change for a number of reasons. > > > So we might be looking at a situation where some tasks get an entire extra > > page > > allocated per task, and some get no difference. And only the average is 24 > > bytes > > increase. > > I think you're right here, at least when it comes to large weirdly-sized > slabs. But _so_ many things affect task_struct that I've never seen > anyone sweat it too much. Makes sense. Then I can't think of any argument to move from case 2.
