On Tue, 13 Aug 2013 16:19:58 -0400 Tejun Heo <t...@kernel.org> wrote:
> Hello, > > On Tue, Aug 13, 2013 at 12:35:12PM -0700, Andrew Morton wrote: > > I don't know how lots-of-kmallocs compares with alloc_percpu() > > performance-wise. > > If this is actually performance sensitive, I've always assumed that it isn't performance-sensitive. schedule_on_each_cpu() has to be slow as a dog. Then again, why does this patchset exist? It's a performance optimisation so presumably someone cares. But not enough to perform actual measurements :( > the logical thing to do > would be pre-allocating per-cpu buffers instead of depending on > dynamic allocation. Do the invocations need to be stackable? schedule_on_each_cpu() calls should if course happen concurrently, and there's the question of whether we wish to permit async schedule_on_each_cpu(). Leaving the calling CPU twiddling thumbs until everyone has finished is pretty sad if the caller doesn't want that. > > That being said, the `cpumask_var_t mask' which was added to > > lru_add_drain_all() is unneeded - it's just a temporary storage which > > can be eliminated by creating a schedule_on_each_cpu_cond() or whatever > > which is passed a function pointer of type `bool (*call_needed)(int > > cpu, void *data)'. > > I'd really like to avoid that. Decision callbacks tend to get abused > quite often and it's rather sad to do that because cpumask cannot be > prepared and passed around. Can't it just preallocate all necessary > resources? I don't recall seeing such abuse. It's a very common and powerful tool, and not implementing it because some dummy may abuse it weakens the API for all non-dummies. That allocation is simply unneeded. -- 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/
