none
Maximum Number of Processor Cores in CLR

    Question

  • Is the maximum number of processors (cores) supported by different versions of the CLR documented somewhere? 

    I'm working on an application hang problem and I can see in dumps that a thread is waiting in mscorwks!ThreadpoolMgr::RecycleMemory for a flag whose address was calculated by using the processor number as an index.  I can't see the index in the dump, but the machine has 48 processors and it looks as though the array containing the flags can accomodate only 32 processors, so the thread might be waiting on something beyond the array.

    Another clue is that there are only 32 GC threads, so I'm suspicious that this CLR will only scale to 32 cores.

    The CLR in use is the 32-bit version of 2.0 running on 64-bit Windows 2008 SP2.  I'd like to see whether there is a restriction on the number of processors in that version and, if so, whether there is another version that would support more.

    Tuesday, May 25, 2010 6:18 PM

Answers

  • Turns out that mscorwks calls GetSystemInfo, not GetNativeSystemInfo. So it's quite possible that you're right.

    If that's the case then it's rather a bug than a restriction in the number of processors. It's one thing if it uses only 32 processors when more are available and it's a different thing if it behaves incorrectly.

    • Proposed as answer by eryang Thursday, June 03, 2010 3:01 AM
    • Marked as answer by eryang Tuesday, June 08, 2010 3:55 AM
    Tuesday, June 01, 2010 10:43 PM
  • Thanks for looking at that, Mike.  SYSTEM_INFO.dwNumberOfProcessors depends on how I populate the SYSTEM_INFO structure:  If I get it by calling by calling GetSystemInfo it gets 32 in WOW64.  If I get it by calling GetNativeSystemInfo, it gets 48.  So the problem that I hypothesize would occur if mscorwks dimensions the array by using the value returned by GetSystemInfo (i.e., 32) and then uses the value returned by NtGetCurrentProcessorNumber (anything from 0 through 47) to index the array.  Can you please see how mscorwks gets the value that it uses for the dimension?

    BTW, the mscorwks version is 2.0.50727.3603, in case that makes a difference.

    In testing we found that if we reduce the number of processor cores on the system from 48 to 32, the problem doesn't occur. 

    Rex

    • Proposed as answer by eryang Thursday, June 03, 2010 3:01 AM
    • Marked as answer by eryang Tuesday, June 08, 2010 3:55 AM
    Tuesday, June 01, 2010 10:12 PM

All replies

  •  

    Actually, some versions of Windows Server 2008 have processor count limitation, from 'Windows Internals Server 2008 Vista' page 41, there is something useful:

    Although Windows was originally designed to support up to 32 processors, nothing inherent

    in the multiprocessor design limits the number of processors to 32—that number is simply an

    obvious and convenient limit because 32 processors can easily be represented as a bit mask using

    a native 32-bit data type. In fact, the 64-bit versions of Windows support up to 64 processors,

    because the native size of a word on a 64-bit machine is 64 bits. The actual number of supported

    processors depends on the edition of Windows being used.

     

    there is also a table shows how many processor supported in different Windows 2008 editions:

    Windows Server 2008 Standard(32bit) --> 4 processors

    Windows Server 2008 Standard(64bit) --> 4 processors

    Windows Server 2008 Enterprise(32bit) --> 8 processors

    Windows Server 2008 Enterprise(64bit) --> 8 processors

    Windows Server 2008 Datacenter(32bit) --> 32 processors

    Windows Server 2008 Datacenter(64bit) --> 64 processors

     

    Since your application is running under WOW64 mode, so there are only 32 processors visible.


    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Thursday, May 27, 2010 1:44 AM
  • Hmmm, my understanding was that those numbers refer to processors (things that go into hardware sockets), as opposed to cores: so by that table, Datacenter would for example support up to 64 processors * 4 (quadcore) = 256 cores.

    Is that so?

    Cristian.

    Thursday, May 27, 2010 3:29 PM
  • Thanks, Eric.  I had forgotten about WOW64 and I'm hazy about how it handles WOW64 processes on systems with more than 32 processors.  In the disassembly of ThreadpoolMgr::RecycleMemory, I can see that mscorwks calls NtGetCurrentProcessorNumber and uses the return value to index into the array of whatever contains the flag that it's waiting on.  But it appears that the array has only 32 elements.  Does WOW64 ensure that NtGetCurrentProcessorNumber doesn't return a value greater than 31? 

    Thanks,

    Rex

    Thursday, May 27, 2010 10:23 PM
  • @Cristian, I think a Processor just refers to a Core, so only 16 CPU (quadcore) is supported on 64bit datacenter.

    @Rex, MS doesn't discuss NtGetCurrentProcessorNumber a lot in its document, could you please do a simple test on your 48 cores machine?


    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Friday, May 28, 2010 9:01 AM
  • Confusing, this link states 64 sockets for 64-bit ... and this too , although it talks about R2.

    Strange that the info is so hard to find on a MS site (to me at least).

    Cristian.

    Friday, May 28, 2010 1:08 PM
  • I wrote an unmanaged 32-bit program to test this.  It starts up N threads and each thread sits in a loop:

    while (true)
    {
      p = GetCurrentProcessorNumber();
      if (p >= ProcLimit)
      {
       printf("Proc: %d, Thread: %d\n", p, s);
      }
    }

    On my system with 48 cores, I ran with ProcLimit = 32 so I could quickly see whether I was getting the (>31) values that I expect to mess up the CLR.  Even with N close to but less than 32, I got processor numbers in the 32 to 47 range. 

    I tried running it with ProcLimit = 50 (so that I wouldn't get any printf output, since that gums up the works) and Task Manager showed that all 48 processor cores were saturated. 

    So it seems to me as though a program running in WOW32 can use more than 32 processor cores.  I tried running a managed program which also started 48 threads.  It also drove all 48 cores whether it was a 64-bit or 32-bit build, so the CLR will at least try to work.  (This was all on 2.0)

    We did a whole lot more searching for documented processor count restrictions in the CLR but didn't find any.

    Rex

    • Edited by Rex Theobald Friday, May 28, 2010 10:41 PM eye test
    Friday, May 28, 2010 10:37 PM
  • All these limitations in Windows (in the current versions) are by socket as you suggested.  I've seen lots more than 64 cores running. 

    Rex

    Friday, May 28, 2010 10:45 PM
  • FYI: that array length is set to SYSTEM_INFO.dwNumberOfProcessors. You may want to check what value dwNumberOfProcessors contains in WOW64, normally it should be the number of cores on the machine but I don't know if WOW64 does something like limiting it to 32.

    Somehow I doubt that the array is not long enough, it is allocated on the heap and writing outside the array should corrupt something sooner or later.

    Maybe it's a CLR bug like this one: http://support.microsoft.com/kb/926594/

    Sunday, May 30, 2010 10:34 AM
  • Thanks for looking at that, Mike.  SYSTEM_INFO.dwNumberOfProcessors depends on how I populate the SYSTEM_INFO structure:  If I get it by calling by calling GetSystemInfo it gets 32 in WOW64.  If I get it by calling GetNativeSystemInfo, it gets 48.  So the problem that I hypothesize would occur if mscorwks dimensions the array by using the value returned by GetSystemInfo (i.e., 32) and then uses the value returned by NtGetCurrentProcessorNumber (anything from 0 through 47) to index the array.  Can you please see how mscorwks gets the value that it uses for the dimension?

    BTW, the mscorwks version is 2.0.50727.3603, in case that makes a difference.

    In testing we found that if we reduce the number of processor cores on the system from 48 to 32, the problem doesn't occur. 

    Rex

    • Proposed as answer by eryang Thursday, June 03, 2010 3:01 AM
    • Marked as answer by eryang Tuesday, June 08, 2010 3:55 AM
    Tuesday, June 01, 2010 10:12 PM
  • Turns out that mscorwks calls GetSystemInfo, not GetNativeSystemInfo. So it's quite possible that you're right.

    If that's the case then it's rather a bug than a restriction in the number of processors. It's one thing if it uses only 32 processors when more are available and it's a different thing if it behaves incorrectly.

    • Proposed as answer by eryang Thursday, June 03, 2010 3:01 AM
    • Marked as answer by eryang Tuesday, June 08, 2010 3:55 AM
    Tuesday, June 01, 2010 10:43 PM
  • Thanks for checking.  I'll open up a case on it and see whether I can get a fix.

    Wednesday, June 02, 2010 7:27 PM
  •  

    Thanks for Mike's help, the issue seems to be a CLR defect,  and the only workaround is to reduce processor count to 32.

    @Rex, could you please post the case link here, so other community members who has similar issue has a place to know the latest status of this case.


    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Thursday, June 03, 2010 3:01 AM
  • The case number is

    110060271121190

    Rex

    Thursday, June 03, 2010 3:43 PM
  • Dear all, the issue has been fixed by product group. You can request the hotfix KB2276255 from Microsoft CSS and check more information from http://support.microsoft.com/KB2276255 which will be published about Sep 15th.   
    Tuesday, August 31, 2010 9:12 AM