On Sat, May 03, 2008 at 07:49:30AM +0200, Nick Piggin wrote:
But taking data on the stack is safe only in the wait=1 case, right?
In that case we may need to go back to the global lock with only one
request being processed at a time. Otherwise, if two wait=1 requests
happen at the same time, they deadlock waiting for each other to process
their request. (See Keith Owens: http://lkml.org/lkml/2008/5/2/183).
In other words, if you want to allow parallel calls to
smp_call_function(), the simplest way to do it seems to be to do the
polling loop. The other ways I have come up with thus far are uglier
and less effective (see http://lkml.org/lkml/2008/4/30/164).
Now, what I -could- do would be to prohibit the wait=1 case from
irq-disable state from polling -- that would make sense, as the caller
probably had a reason to mask irqs, and might not take kindly to having
them faked behind the caller's back. ;-)
OK, so let me make sure I understand what is needed. One example might be
some code called from scheduler_tick(), which runs with irqs disabled.
Without the ability to call smp_call_function() directly, you have
to fire off a work queue or something. Now, if smp_call_function()
can hand you an -ENOMEM or (maybe) an -EBUSY, then you still have to
fire off the work queue, but you probably only have to do it rarely,
minimizing the performance impact.
Another possibility is when it is -nice- to call smp_call_function(),
but can just try again on the next scheduler_tick() -- ignoring dynticks
idle for the moment. In this case, you might still test the error return
to set a flag that you will check on the next scheduler_tick() call.
Is this where you guys are coming from?
And you are all OK with smp_call_function() called with irqs enabled
never being able to fail, right? (Speaking of spaghetti code, why
foist unnecessary failure checks on the caller...)
OK, I think I might be seeing what you guys are getting at. Here is
what I believe you guys need:
1. No deadlocks, ever, not even theoretical "low probability"
deadlocks.
2. No failure returns when called with irqs enabled. On the other
hand, when irqs are disabled, failure is possible. Though hopefully
unlikely.
3. Parallel execution of multiple smp_call_function() requests
is required, even when called with irqs disabled.
4. The wait=1 case with irqs disabled is prohibited.
5. If you call smp_call_function() with irqs disabled, then you
are guaranteed that no other CPU's smp_call_function() handler
will be invoked while smp_call_function() is executing.
Anything I am missing?
Thanx, Paul
--
