[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <90a70461d15b9053e0507beda20b448194ba5eb4.camel@intel.com>
Date: Thu, 11 Jul 2024 22:55:17 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "Yang, Weijiang" <weijiang.yang@...el.com>, "Hansen, Dave"
<dave.hansen@...el.com>, "seanjc@...gle.com" <seanjc@...gle.com>,
"x86@...nel.org" <x86@...nel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "tglx@...utronix.de" <tglx@...utronix.de>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "pbonzini@...hat.com"
<pbonzini@...hat.com>
CC: "peterz@...radead.org" <peterz@...radead.org>, "john.allen@....com"
<john.allen@....com>, "Gao, Chao" <chao.gao@...el.com>, "mlevitsk@...hat.com"
<mlevitsk@...hat.com>
Subject: Re: [PATCH 0/6] Introduce CET supervisor state support
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.
Powered by blists - more mailing lists