On Wed, Jan 19, 2011 at 9:38 AM, Rafael J. Wysocki [off-list ref] wrote:

On Wednesday, January 19, 2011, Jeff Chua wrote:

quoted

On Wed, Jan 19, 2011 at 4:20 AM, Rafael J. Wysocki [off-list ref] wrote:

quoted

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

quoted

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html