Messages in this thread | | | Date | Sun, 24 Jun 2012 05:16:52 +0100 | From | Al Viro <> | Subject | Re: deferring __fput() |
| |
On Sat, Jun 23, 2012 at 10:01:41PM +0100, Al Viro wrote: > On Sat, Jun 23, 2012 at 10:38:00PM +0200, Oleg Nesterov wrote: > > > > Matter of fact, it would become identical to struct rcu_head > > > after that... > > > > This is not clear to me... Why this is good? > > Occam's Razor. > > > I understand that sizeof(task_work) == sizeof(rcu_head) would be > > nice, probably you meant just this? > > More than that - the callback type is also the same (pointer to such > struct -> void). IOW, they both look like two instances of the > same thing ("list of callbacks"), differing only in what and > when does calling.
BTW, I suspect that we really want to move exit_task_work() down past the calls of exit_mm()/exit_files() (and lose the PF_EXITING check in task_work_add(), making that ordering responsibility of callers). It's not strictly necessary - we can just treat PF_EXITING the same way we treat PF_KTHREAD, but that means driving those final fput on exit through schedule_work(). Extra context switch...
I'm not 100% sure about that one - if you have planned task_work users relying on e.g. task->mm still being there when callback runs, we obviously can't go that way, but it would be nice to have. AFAICS, existing users are fine with such reordering.
We could, in principle, add a "ok_late" argument, allowing to add after PF_EXITING has been set only if it's true and run the list twice, but that's really more convoluted than I would like...
Comments?
| |