Hello, Chris. On Fri, Aug 09, 2013 at 12:12:43PM -0400, Chris Metcalf wrote: > I could certainly make schedule_on_cpu_mask() do sanity checking, > perhaps via a WARN_ON_ONCE() if offline cpus were specified, and > otherwise just have it create a local struct cpumask that it and's > with cpu_online_mask, suitably wrapping with > get_online_cpus()/put_online_cpus(). (I'm not sure how to test if a > cpu has ever been online, vs whether it's online right now.) I I think you'll have to collect it from CPU_ONLINE of workqueue_cpu_up_callback() and I think it probably wouldn't be a bad idea to allow scheduling on CPUs which have been up but aren't currently as that's the current rule for other interfaces anyway. > don't want to unnecessarily slow down the existing > schedule_on_each_cpu(), so perhaps the implementation should have a > static schedule_on_cpu_mask_internal() function that is the same as > my previous schedule_on_cpu_mask(), allowing schedule_on_each_cpu() > to call it directly to bypass the checking. Hmmm.... it's unlikely to make noticeable difference given that it's gonna be bouncing multiple cachelines across all online CPUs. > That said... I wonder if it might make sense to treat this API the > same as other APIs that already take a cpu? schedule_work_on(), > schedule_delayed_work_on(), and queue_delayed_work_on() all take a > cpu parameter without API comment or validity checking; > queue_work_on() just says "the caller must ensure [the cpu] can't go > away". Does it make sense to just add a similar comment to > schedule_on_cpu_mask() rather than make this API the first to > actually do cpu validity checking? Yeah, we've been lazy with the sanity check and I think it's a good opportunity to add it. Let's worry about other paths later. Thanks. -- tejun -- 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>