On our test machine that has 1664 processors, we've discovered that > the function acpi_processor_get_throttling_info takes 10 minutes. > It's estimated that with 4096 cpus, this will take over 25 minutes. > > It seems that the acpi_processor_get_throttling_info serially queries > each cpu with a "runon" function to extract the throttling states. > > My question is can this be optimized to use the previous processor's > throttling states? Would there be any reason to expect any of the > processors to be different? > > Another thought, if each processor needs to be queried, can the > functions be run in parallel? >
Created attachment 26163 [details] console log output Here's the output from the console. The cmdline options were: root=LABEL=sgiroot1S1 kdb=on pcie_aspm=off add_efi_memmap cgroup_disable=memory earlyprintk=ttyS0,115200n8 log_buf_len=8M processor.max_cstate=1 stop_machine.lazy=1 splash=silent crashkernel=256M-:128M showopts console=ttyS0,115200n8 ignore_loglevel maxcpus=4 acpi.debug_layer=0x20000000 Note that it still walked all 1664 processors even with maxcpus=4! 1st message: [ 132.642893] processor_core-0609 [00] processor_get_info : Bus mastering arbitration control present last message: [ 968.133536] processor_throttling-0217 [00] processor_throttling_i: Assume no T-state coordination 13+ minutes elapsed time.
Created attachment 26164 [details] gzipped acpidump info
Created attachment 26244 [details] Optimize method termination
Comment on attachment 26244 [details] Optimize method termination Please check if the patch makes any difference
Created attachment 26262 [details] Split Parent from Peer Node list Please check if this patch makes any effect.
Bug closed as there is no response from the bug reporter for more than a month. please re-open it if you can try the patch in comment #4 and #5.
Hi, I'm a bit confused on the state here. Are there two incidents filed for this same issue? There was a fix applied and it seems to work. Are you asking me to try an alternative version? Sorry for the delay in responding, as you may know we are going through the process of MR'ing the UV system and the code has been frozen. I will get a chance soon to try out anything extra that may be applied post-MR. Thanks, Mike
(In reply to comment #7) > Hi, > > I'm a bit confused on the state here. Are there two incidents filed for this > same issue? There was a fix applied and it seems to work. Are you asking me > to try an alternative version? > Oh, there is no test results about any of the patches in this bug report, that's why I mark it as INSUFFICIENT_DATA. would you please attach the url about the test result? > Sorry for the delay in responding, as you may know we are going through the > process of MR'ing the UV system and the code has been frozen. I will get a > chance soon to try out anything extra that may be applied post-MR. > Okay, that would be great.
> There was a fix applied and it seems to work. closed.