On Tue, 13 Aug 2013 16:19:58 -0400 Tejun Heo <tj@xxxxxxxxxx> 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, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>