Messages in this thread | | | Date | Tue, 29 Jul 2014 09:36:47 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH RFC tip/core/rcu 1/9] rcu: Add call_rcu_tasks() |
| |
On Tue, Jul 29, 2014 at 10:12:11AM +0200, Peter Zijlstra wrote: > On Mon, Jul 28, 2014 at 03:56:12PM -0700, Paul E. McKenney wrote: > > + /* > > + * Each pass through the following loop scans the list > > + * of holdout tasks, removing any that are no longer > > + * holdouts. When the list is empty, we are done. > > + */ > > + while (!list_empty(&rcu_tasks_holdouts)) { > > + schedule_timeout_interruptible(HZ / 10); > > + flush_signals(current); > > + rcu_read_lock(); > > + list_for_each_entry_rcu(t, &rcu_tasks_holdouts, > > + rcu_tasks_holdout_list) { > > + if (smp_load_acquire(&t->rcu_tasks_holdout)) > > + continue; > > + list_del_init(&t->rcu_tasks_holdout_list); > > + /* @@@ need to check for usermode on CPU. */ > > + } > > + rcu_read_unlock(); > > + } > > That's a potential CPU runtime sink.. imagine having to scan 100k tasks > 10 times a second. Polling O(nr_tasks) is not good.
This only scans those tasks that are blocking the RCU-tasks grace period, and this list should get shorter reasonably quickly as each task does a voluntary context switch.
Of course, there is the do_each_thread() / while_each_thread() loop that builds this list, and yes, that does look at each and every task, as does the subsequent loop that waits for pre-existing partially exited tasks to disappear from the list. As noted in an earlier email, I am taking Steven at his word when he said that updates are very infrequent and that he doesn't care about the latency and overhead of the updates.
Thanx, Paul
| |