[lkml]   [2008]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 1/7] work_on_cpu: helper for doing task on a CPU.
    On Fri, Oct 24, 2008 at 12:29:57PM +0200, Oleg Nesterov wrote:
    > On 10/24, Gautham R Shenoy wrote:
    > >
    > > On Fri, Oct 24, 2008 at 02:04:35PM +1100, Rusty Russell wrote:
    > > >
    > > > I think we should BUG_ON(per_cpu(cpu_state, cpuid) != CPU_DEAD) to ensure we
    > > > never use work_on_cpu in the hotplug cpu path. Then we use
    > > > smp_call_function() for that hard intel_cacheinfo case. Finally, we fix the
    > > > cpu hotplug path to use schedule_work_on() itself rather than playing games
    > > > with cpumask.
    > > >
    > > > If you agree, I'll spin the patches...
    > >
    > > How about the following?
    > >
    > > We go with this method, but instead of piggybacking on
    > > the generic kevents workqueue, we create our own on_each_cpu_wq, for this
    > > purpose.
    > Gautham, Rusty, I am a bit lost on this discussion...
    > Why should we care about this deadlock? Just do not use work_on_cpu() from
    > the hotplug cpu path, that is all.
    > Once again, the "cpu_hotplug_begin()" lock is not special. You can't use
    > work_on_cpu() under (say) rtnl_lock() for the same reason, this lock is
    > used by work->func() too.
    > Perhaps I missed something, and work_on_cpu() is really important for
    > cpu-hotplug path?

    Rusty, Oleg,

    Having a rule that we shouldn't use work_on_cpu() in cpu-hotplug path
    is a good thing. But maintaining it can be difficult.

    We've seen that in the past with the cpucontrol mutex.
    We had clear rules that functions which get called in
    cpu-hotplug callback paths, shouldn't take this mutex. But with
    functions that were called in the cpu-hotplug notifier
    path as well as normal paths, it created a whole locking mess,
    and took quite some time to fix.

    Similarly, right now, we can have a BUG_ON() which notifies us whenever
    someone ends up calling a function that invokes work_on_cpu() from the
    CPU-Hotplug callpath. But we will fix it only when the BUG_ON() is hit.

    On the other hand, if we have a mechanism that's guaranteed to work
    irrespective of the callpaths, why not use that ?

    I am not opposed to the proposed design.
    Just voicing out an alternative thought. I could be completely wrong :-)

    > Oleg.
    > --
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to
    > More majordomo info at
    > Please read the FAQ at

    Thanks and Regards

     \ /
      Last update: 2008-10-24 13:43    [W:0.025 / U:10.876 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site