On Thu, Jul 31, 2014 at 07:27:52PM +0200, Oleg Nesterov wrote: > On 07/31, Paul E. McKenney wrote: > > > > On Thu, Jul 31, 2014 at 06:31:38PM +0200, Oleg Nesterov wrote: > > > > > But can't we avoid get_task_struct()? This can pin a lot of task_struct's. > > > Can't we just add list_del_rcu(holdout_list) into __unhash_process() ? > > > > If I add the list_del_rcu() there, then I am back to a concurrent list, > > which I would like to avoid. Don't get me wrong, it was fun playing with > > the list-locked stuff, but best to avoid it if we can. > > OK, > > > The nice thing about using get_task_struct to lock > > them down is that -only- the task_struct itself is locked down -- the > > task can be reaped and so on. > > I understand. but otoh it would be nice to not pin this memory if the > task was already (auto)reaped. > > And afaics the number of pinned task_struct's is not bounded. In theory > it is not even limited by, say, PID_MAX_LIMIT. A thread can exit and reap > itself right after get_task_struct() but create another running thread > which can be noticed by rcu_tasks_kthread() too.
Good point! Maybe this means that I need to have rcu_struct_kthread() be more energetic if memory runs low, perhaps via an OOM handler. Would that help? > > > We only need to ensure that list_add() above can't race with that > > > list_del(), > > > perhaps we can tolerate lock_task_sighand() ? > > > > I am worried about a task that does a voluntary context switch, then exits. > > This could results in rcu_tasks_kthread() and __unhash_process() both > > wanting to dequeue at the same time, right? > > Oh yes, I was very wrong. And we do not want to abuse tasklist_lock... > > OK, let me try to read the patch first. Not a problem, looking forward to your feedback! Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/