Hi, 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? Each time I broke into this delay, this was the call stack: 6.559522 ( 0.000032)| Stack traceback for pid 16894 6.559554 ( 0.000032)| 0xffff8827fb4d8680 16894 1 1 358 R 0xffff8827fb4d8d10 modprobe 6.559628 ( 0.000074)| ffff8827fb535ae0 0000000000000018 ffffffff81246665 ffff8ac700000004 6.559694 ( 0.000066)| ffff8d21fc07d150 ffff8ac7fc2e8800 0000000000000000 ffff8ac7fc2e9550 6.559771 ( 0.000077)| 0000000000000000 ffff8827fb535cd8 ffffffff81235822 ffffffff8158ac76 6.559837 ( 0.000066)| Call Trace: 6.559852 ( 0.000015)| Inexact backtrace: 6.559874 ( 0.000022)| 6.559879 ( 0.000005)| [<ffffffff81246665>] ? acpi_ns_delete_namespace_by_owner+0xb2/0xdb 6.559944 ( 0.000065)| [<ffffffff81235822>] ? acpi_ds_terminate_control_method+0x74/0x102 6.560008 ( 0.000064)| [<ffffffff8124a60f>] ? acpi_ps_parse_aml+0x246/0x3c9 6.560061 ( 0.000053)| [<ffffffff81251e25>] ? acpi_ut_create_internal_object_dbg+0x18/0x79 6.560129 ( 0.000068)| [<ffffffff8124be20>] ? acpi_ps_execute_method+0x229/0x331 6.560194 ( 0.000065)| [<ffffffff81246851>] ? acpi_ns_evaluate+0x189/0x2bc 6.560246 ( 0.000052)| [<ffffffff8124611c>] ? acpi_evaluate_object+0x15e/0x2a5 6.560301 ( 0.000055)| [<ffffffff812513e8>] ? acpi_ut_update_ref_count+0x17f/0x1d6 6.560386 ( 0.000085)| [<ffffffffa012e14c>] ? acpi_processor_get_throttling_info+0x202/0x6f9 [processor] 6.560464 ( 0.000078)| [<ffffffffa0131c46>] ? acpi_processor_add+0x93a/0xa8c [processor] 6.560528 ( 0.000064)| [<ffffffff8122b247>] ? acpi_device_probe+0x4e/0x179 6.560580 ( 0.000052)| [<ffffffff8128cb28>] ? driver_probe_device+0xc8/0x2d0 6.560633 ( 0.000053)| [<ffffffff8128cdc3>] ? __driver_attach+0x93/0xa0 6.560682 ( 0.000049)| [<ffffffff8128cd30>] ? __driver_attach+0x0/0xa0 6.560740 ( 0.000058)| [<ffffffff8128c158>] ? bus_for_each_dev+0x58/0x80 6.560790 ( 0.000050)| [<ffffffff8128b945>] ? bus_add_driver+0x155/0x2b0 6.560839 ( 0.000049)| [<ffffffffa00d0000>] ? acpi_processor_init+0x0/0x10e [processor] 6.560902 ( 0.000063)| [<ffffffff8128d0d9>] ? driver_register+0x79/0x170 6.560952 ( 0.000050)| [<ffffffffa00d0000>] ? acpi_processor_init+0x0/0x10e [processor] 6.561015 ( 0.000063)| [<ffffffffa00d009a>] ? acpi_processor_init+0x9a/0x10e [processor] 6.561079 ( 0.000064)| [<ffffffff81067325>] ? __blocking_notifier_call_chain+0x65/0x90 6.561141 ( 0.000062)| [<ffffffff810001e5>] ? do_one_initcall+0x35/0x190 6.561190 ( 0.000049)| [<ffffffff8107b514>] ? sys_init_module+0xe4/0x270 6.561240 ( 0.000050)| [<ffffffff81002e7b>] ? system_call_fastpath+0x16/0x1b Thanks, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
