{"id":705,"date":"2019-04-03T00:27:22","date_gmt":"2019-04-03T00:27:22","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/maoni\/?p=705"},"modified":"2019-09-23T15:48:35","modified_gmt":"2019-09-23T22:48:35","slug":"making-cpu-configuration-better-for-gc-on-machines-with-64-cpus","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/making-cpu-configuration-better-for-gc-on-machines-with-64-cpus\/","title":{"rendered":"Making CPU configuration better for GC on machines with > 64 CPUs"},"content":{"rendered":"

If you are running Windows on a machine with > 64 CPUs, you\u2019ll need to use this feature called the CPU groups for your process to be able to use more than 64 CPUs. At some point in the far distant past, people thought having more than 64 processors on a machine was inconceivable so they used a 64-bit number for the processor mask. And when 64-proc machines became available, Windows invented this CPU group<\/a> concept for such machines which says processors are now belong to different CPU groups where each group has no more than 64 procs. Eg, on a machine with 96 procs you will see 2 groups with 48 procs each. When a process starts, it always starts in a single CPU group. The only way to use processors from other groups is for this process to set its thread affinity so it will run on processors from other groups. When machines with > 64 procs became available, we added a config called GCCpuGroup<\/a>. The default for it is 0 (ie, enabled=false) meaning without this config, if you are using Server GC, the process would create at most N Server GC threads\/heaps where N is the # of processors in the single group it started in. When this is set to 1, GC will create Server GC threads that span all active processors in all available CPU groups on the machine. Then our runtime started to run on Linux and with that we introduced an OS layer that GC calls via GCToOSInterface which abstracted away the OS functionalities GC needed, eg, VirtualAlloc and processor affinity. And we had our Linux OS layer simulated the Windows behavior. For the most part this was desired but there\u2019s one thing that became more and more a thorny point \u2013 it\u2019s the CPU group concept. Linux does not have this concept \u2013 if you have > 64 processors you will get to use 64 procs without doing anything special. And we had to write all this code in our Linux OS layer to group processors into CPU groups. Recently we decided to pull the plug on this and no longer have Linux simulate the Windows behavior \u2018cause we like the Linux behavior better for this particular case. I\u2019ve been working with Jan Vorlicek <\/a>on this (he\u2019s doing all the work). The main pieces of this work are the following \u2013 1) GC will no longer have the concept of CPU groups. Checks like this: