Re: [RFC PATCH 0/6] Introduce cluster cpu topology support

[wangyanan (Y)]

On 2021/4/27 20:08, Philippe Mathieu-Daudé wrote:
> On 4/27/21 1:00 PM, wangyanan (Y) wrote:
> > On 2021/4/27 17:57, Philippe Mathieu-Daudé wrote:
> > > On 3/31/21 11:53 AM, Yanan Wang wrote:
> > > > Hi,
> > > > This series introduces the cluster cpu topology support, besides now
> > > > existing sockets, cores, and threads.
> > > >
> > > > A cluster means a group of cores that share some resources (e.g. cache)
> > > > among them under the LLC. For example, ARM64 server chip Kunpeng 920 has
> > > > 6 or 8 clusters in each NUMA, and each cluster has 4 cores. All clusters
> > > > share L3 cache data while cores within each cluster share the L2 cache.
> > > >
> > > > Also, there are some x86 CPU implementations (e.g. Jacobsville) where L2
> > > > cache is shared among a cluster of cores instead of being exclusive to
> > > > one single core. For example, on Jacobsville there are 6 clusters of 4
> > > > Atom cores, each cluster sharing a separate L2, and 24 cores sharing
> > > > L3).
> > > > About this series:
> > > > Note that, this series was implemented based on [3] and [4]. Although
> > > > they
> > > > have not merged into qemu mainline for now, it's still meaning to
> > > > post this
> > > > series to express the thoughts first. So a RFC is sent and any
> > > > comments are
> > > > welcomed and appreciated.
> > > At a glance: tests/unit/test-x86-cpuid.c should be adapted to be generic
> > > (but still supporting target-specific sub-tests) and some aarch64 tests
> > > added.
> > >
> > > Similarly the ARM PPTT tables tested in tests/qtest/bios-tables-test.c.
> > >
> > > Otherwise, the overall series looks good and coherent, but it isn't my
> > > area :)
> > Thank you for the reminder of the related tests. :)
> > I will have some work to make them cover the new features introduced
> > by this series.
> BTW if after 4 weeks and 2 pings nobody sent negative feedback or
> NAcked your series, it usually means the community is not against
> your purposal, but has some doubts this feature is necessary or
> well designed. Tests help to show your work is safe, as it doesn't
> break anything. You might need to better explain why this feature
> is needed, and what are the limitations of what is currently
> possible.
>
> OTOH QEMU has been in "feature freeze" for the next v6.0 release
> for the same amount of time, so maybe the maintainers/reviewers
> were busy with bugs and still have your series in their TODO list.
I fully understand your point, and thanks for the explanations.

I will just patiently wait for some feedback, and of course on the same 
time,
will also refine the solution with some convincing tests for later new 
version.

Thanks,
Yanan
> Regards,
>
> Phil.
>
> .