Message ID | 20210331095343.12172-1-wangyanan55@huawei.com |
---|---|
Headers | show |
Series | Introduce cluster cpu topology support | expand |
On 31/03/21 11:53, Yanan Wang wrote: > 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. Is this different from what we already have with "-smp dies"? Paolo
Hi Paolo, On 2021/3/31 18:00, Paolo Bonzini wrote: > On 31/03/21 11:53, Yanan Wang wrote: >> 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. > > Is this different from what we already have with "-smp dies"? As far as I know, yes. I think they are two architecture concepts of different levels. A cpu socket/package can consist of multiple dies, and each die can consist of multiple clusters, which means dies are parent for clusters. And this kind of cpu hierarchy structure is normal in ARM64 platform. Still take above ARM64 server chip Kunpeng 920 as an example, there totally are 2 sockets, 2 dies in each socket, 6 or 8 clusters in each die, and 4 cores in each cluster. Since it also supports NUMA architecture, then each NUMA actually represents one die. Although there is already "-smp dies=*" command line parameter for PC Machines, a cluster level can be added for x86 architecture if meaningful and there will be more work to do in qemu to make use of it. And I am sure that ARM needs this level. If there is something wrong above, please correct me, thanks! Thanks, Yanan > > Paolo > > .
Hi Yanan, 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 :) Regards, Phil.
Hi Philippe, On 2021/4/27 17:57, Philippe Mathieu-Daudé wrote: > Hi Yanan, > > 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. Thanks, Yanan > > Regards, > > Phil. > > .
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. Regards, Phil.
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. > > .