Re: [PATCH 3/3] serial: 8250: Add a wakeup_capable module param

On Monday, January 23, 2012, Paul E. McKenney wrote:

On Sat, Jan 21, 2012 at 12:49:35AM +0100, Rafael J. Wysocki wrote:

quoted

On Friday, January 20, 2012, Paul E. McKenney wrote:

quoted

On Fri, Jan 20, 2012 at 01:03:34AM +0100, Rafael J. Wysocki wrote:

quoted

On Thursday, January 19, 2012, Paul E. McKenney wrote:

quoted

On Thu, Jan 19, 2012 at 01:02:58AM +0100, Rafael J. Wysocki wrote:

quoted

On Wednesday, January 18, 2012, Paul E. McKenney wrote:

quoted

On Wed, Jan 18, 2012 at 02:15:59PM -0800, Simon Glass wrote:

[...] 

quoted

quoted

Yes, you can, but then I'd say it's not necessary for user space to
be able to carry that out in a tight loop.  So, it seems, alternatively,
we could make that loop a bit less tight, e.g. by adding an arbitrary
sleep to the user space interface for the "disable" case.

Good point, that would work just as well and be simpler.

Thanks for the confirmation! :-)

By the way, I wonder, would it help to add synchronize_rcu() to
wakeup_source_add() too?  Then, even if device_wakeup_enable() and
device_wakeup_disable() are executed in a tight loop for the same
device, the list_add/list_del operations will always happen in
different RCU cycles (or at least it seems so).

I cannot immediately see how adding a synchronize_rcu() to
wakeup_source_add() would help anything.  You only need to wait for a
grace period on removal, not (normally) on addition.  The single grace
period during removal will catch up all other asynchronous RCU grace
period requests on that CPU.

Or am I missing your point?

Well, I was thinking about the failure scenario you mentioned where
executing enable/disable in a tight loop might exhaust system memory
(if I understood it correctly).

Ah, got it.  If they are executing this in a tight loop, there will be
little difference between doing one synchronize_rcu() per pass through
the loop or doing two.  So we should be just fine with the single instance
of synchronize_rcu() per loop.

Good! :-)

Thanks a lot,
Rafael