Re: [PATCH v10 2/5] i386: Populate AMD Processor Cache Information for cpuid 0x8000001D

From: "Moger, Babu" <Babu.Moger@amd.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: "geoff@hostfission.com" <geoff@hostfission.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"mst@redhat.com" <mst@redhat.com>,
	"kash@tripleback.net" <kash@tripleback.net>,
	"mtosatti@redhat.com" <mtosatti@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"Duran, Leo" <leo.duran@amd.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"rth@twiddle.net" <rth@twiddle.net>
Subject: Re: [PATCH v10 2/5] i386: Populate AMD Processor Cache Information for cpuid 0x8000001D
Date: Wed, 23 May 2018 16:18:17 +0000	[thread overview]
Message-ID: <DM5PR12MB24715AE7662F1F1D571832B9956B0@DM5PR12MB2471.namprd12.prod.outlook.com> (raw)
In-Reply-To: <20180522140339.GC25013@localhost.localdomain>


> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Tuesday, May 22, 2018 9:04 AM
> To: Moger, Babu <Babu.Moger@amd.com>
> Cc: Duran, Leo <leo.duran@amd.com>; mst@redhat.com;
> marcel.apfelbaum@gmail.com; pbonzini@redhat.com; rth@twiddle.net;
> mtosatti@redhat.com; qemu-devel@nongnu.org; kvm@vger.kernel.org;
> kash@tripleback.net; geoff@hostfission.com
> Subject: Re: [PATCH v10 2/5] i386: Populate AMD Processor Cache
> Information for cpuid 0x8000001D
> 
> On Tue, May 22, 2018 at 01:32:52PM +0000, Moger, Babu wrote:
> >
> > > -----Original Message-----
> > > From: Duran, Leo
> > > Sent: Monday, May 21, 2018 8:32 PM
> > > To: Moger, Babu <Babu.Moger@amd.com>; mst@redhat.com;
> > > marcel.apfelbaum@gmail.com; pbonzini@redhat.com; rth@twiddle.net;
> > > ehabkost@redhat.com; mtosatti@redhat.com
> > > Cc: qemu-devel@nongnu.org; kvm@vger.kernel.org;
> kash@tripleback.net;
> > > geoff@hostfission.com
> > > Subject: RE: [PATCH v10 2/5] i386: Populate AMD Processor Cache
> > > Information for cpuid 0x8000001D
> > >
> > > Babu,
> > >
> > > If num_sharing_l3_cache() uses MAX_NODES_EPYC, then that function
> It’s
> > > EPYC specific.
> > >
> > > An alternative would be to use a data member (e.g.,
> > > max_nodes_per_socket)) that get initialized (via another helper
> function) to
> > > MAX_NODES_EPYC.
> >
> > Thanks Leo.  Let me see how we can handle this. This requires changes in
> generic
> > Data structure which I tried to avoid here.  I will wait for all the comments
> for whole
> > series before making this change.  Note that right now, this feature is only
> enabled
> > for EPYC. Yes. I know this could this in future.
> 
> We just need a reasonable default, by now, and it can even be the
> same value used on EPYC.  This default just need to generate
> reasonable results for other cases that don't match real hardware
> (like cores=32 or cores=12).

Ok. Will change the name to bit generic for now and keep the defaults as in EPYC.
> 
> --
> Eduardo