On Thu, Jun 16, 2011 at 10:25:50PM +0200, Ingo Molnar wrote:

* Paul E. McKenney [off-list ref] wrote:

quoted

quoted

The funny thing about this workload is that context-switches are 
really a fastpath here and we are using anonymous IRQ-triggered 
softirqs embedded in random task contexts as a workaround for 
that.

The other thing that the IRQ-triggered softirqs do is to get the 
callbacks invoked in cases where a CPU-bound user thread is never 
context switching.

Yeah - but this workload didnt have that.

quoted

Of course, one alternative might be to set_need_resched() to force 
entry into the scheduler as needed.

No need for that: we can just do the callback not in softirq but in 
regular syscall context in that case, in the return-to-userspace 
notifier. (see TIF_USER_RETURN_NOTIFY and the USER_RETURN_NOTIFIER 
facility)

Abusing a facility like setting need_resched artificially will 
generally cause trouble.

If the task enqueued callbacks in the kernel, thus started a new grace period,
it might return to userspace before every CPUs have completed that grace period,
and you need that full completion to happen before invoking the callbacks.

I think you need to keep the tick in such case because you can't count on
the other CPUs to handle that completion as they may be all idle.

So when you resume to userspace and you started a GP, either you find another
CPU to handle the GP completion and callbacks executions, or you keep the tick
until you are done.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>