On Fri, Apr 20, 2012 at 08:56:57AM -0700, Linus Torvalds wrote: > > We also get something else out of that - AFAICS, the kludge in __scm_destroy() > > can be killed after that. ?We did it to prevent recursion on fput(), right? > > Now that recursion will be gone... > > Hmm.. That points out that we may have a *lot* of these pending final > fput's, though. So the deferral queueing should be fairly light. What > were your particular plans for it? Doing removal from per-sb list immediately (i.e. before possible deferral; we skip ones with zero ->f_count when we walk the list anyway), then in case we decide to defer just move them to per-CPU list and schedule work on that CPU, with handler that will pull the corresponding list out and do the rest of __fput() for everything in that list. No extra locking, just preempt_disable() around the "move to per-CPU list" bit. Or a per-CPU spinlock with worker not being tied to specific CPU and told which CPU's list to work with. How does CPU hotplug interact with work scheduled on CPU about to be taken down, BTW? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
