Distribution: Hardware Environment: Software Environment: 2.6.5-rc2 Problem Description: If acpi uses keventd thread by callind schedule_work() then higher level driver like processor drivers can not call schedule_work() and wait for it to execute. Also acpi having its own thread simplifies lot of things for future CPU/Memory/IO hotplug implementations. Steps to reproduce:
Created attachment 2604 [details] acpi_os_queue_for_execution() queues the work to "acpid" thread
In the current ACPI implementation, when an hardware SCI event happens the ACPI driver queues the work on to keventd thread by calling schedule_work(), as acpi does not have its own thread. As we are working on to support CPU hotplugging in the near futures, the requirement for CPU hot plugging is that, in case of CPU_DOWN, we need to migrate all the work queued on to the dying CPU's keventd thread to different CPU's keventd thread and we are forced to kill the keventd thread of the dying CPU. The problem with the above for CPU hot plugging is that, if the hardware SCI event for CPU removal queues the work request to the CPU that needs to be removed, then the keventd thread running CPU_DOWN code to remove the CPU needs to be killed as part of the CPU removal process and since we are running on the same thread, we would end up in a dead lock. To better prepare ACPI for CPU hotplugging, here is what I would like to propose. Let ACPI have its own thread to execute the SCI/hardware events notification callbacks. Let the acpi queues the work request onto to this thread instead of keventd thread. In the ACPI there is a function called acpi_os_queue_for_execution() and in this function instead of calling schedule_work() I am now queuing the work on to acpi's own thread by calling acpi_os_schedule_work(). The benefit of this is approach is that 1) Higher level drivers/protocol can call schedule_work() and can wait for it to execute(since the event handler will be running on acpi's event thread and not kevents thread). 2) Events queued to ACPI's own thread can get executed faster than the one queued to the keventd thread. 3) Of course, ACPI can support CPU hot plugging.
Great. And maybe we should implement a synchronizing mechanism for the queue as well. eg. wait all events in the queue are completed. I have a patch to address it (Bug 1171), but if your patch applied, it should be revised.
Hi Shaohua, I would be happy to implement the synchronization mechanisms for the queue, please can you send me your patch which address it, so that I can port that to mine. Thanks, Anil
Created attachment 2615 [details] added synchronization mechanization by implementing acpi_os_wait_events_complete() This patch depends on the first attached patch and also covers bug 1117 i.e http://bugme.osdl.org/show_bug.cgi?id=1171. I was able to test very minimal functionality with this patch, just to make sure the implementation is not breaking any stuff. Thanks, Anil
Created attachment 2627 [details] queued task gets executed only from the acpid thread. Made sure that the queued events gets executed only from kacpid thread and not from any arbitary thread which calls acpi_os_wait_events_complete(). Again this patch depends on attachement 2604
Created attachment 2649 [details] This patch is much simpler and uses create_singlethread_workqueue() kernel call to create a thread This patch is against linux-2.6.6-rc2 and this is much simpler and cleaner than the earlier patches.
This looks much clean. And I think the parameter of 'acpi_os_wait_events_complete' should be deleted, since implement 'wait context' is difficult in work queue, and currently we didn't use it.
*** Bug 2622 has been marked as a duplicate of this bug. ***
*** Bug 1171 has been marked as a duplicate of this bug. ***
shipped in Linux-2.6.7 not applied to 2.4