On Wed, Jan 19, 2011 at 9:38 AM, Rafael J. Wysocki <rjw@xxxxxxx> wrote:
> On Wednesday, January 19, 2011, Jeff Chua wrote:
>> On Wed, Jan 19, 2011 at 4:20 AM, Rafael J. Wysocki <rjw@xxxxxxx> wrote:
>> > Please apply the appended patch (without the previous one) and post a dmesg
>> > log containing a suspend-resume cycle with the delay. I wonder where exactly
>> > the delay occurs.
>> > + pr_info("%s: synchronize_rcu()\n", __func__);
>> > synchronize_rcu();
>> > + pr_info("%s: iounmap(%p), physaddr: %llx, size: %u\n", __func__,
>> > + map->virt, map->phys, map->size);
>>
>> Rafael,
>>
>> The 30 seconds is due to this ...
>>
>> PM: Syncing filesystems ... done.
>> Freezing user space processes ... _memory: synchronize_rcu()
>> acpi_os_unmap_memory: iounmap(ffffc90001c22000), physaddr: bb398000, size: 4096
>> acpi_os_unmap_memory: synchronize_rcu()
>> acpi_os_unmap_memory: iounmap(ffffc90001c26000), physaddr: bb399000, size: 4096
00), physaddr: bb79e000, size: 4096
>> Restarting tasks ... done.
>>
>> After this, I see my X windows.
>
> Are you able to say whether the synchronize_rcu() or the iounmap() calls block?
It's "synchronize_rcu()" that's causing the slow down. Removing it
solves the problem.
Does synchronize_rcu() triggers the limiting update rate as described
in Documentation/RCU/whatisRCU.txt?
In addition, the synchronize_rcu() API has the nice property
of automatically limiting update rate should grace periods
be delayed. This property results in system resilience in face
of denial-of-service attacks.
Thanks,
Jeff
--
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
