RE: [lhcs-devel] Fw: Re: (sigh) smp_call_function again

[Raj, A. <ash...@in...>]

Thanks Srivatsa

>
>Raj,
>	Unlike smp_call_function, flush_tlb_others sends the
>INVALIDATE_TLB_VECTOR IPI to select CPUs (that are in a task's
vm_mask).
>With this in mind, I don't think we ever should end up with a stale
>INVALIDATE_TLB_VECTOR IPI on the dead CPU.

That makes sense, since we also migrate all tasks away, and doing a
flush_tlb_all() that should make sure no more of this type IPI would
happen.

>
>However, yes, we can see stale RESCHEDULE_VECTOR IPI(?) ..

As Rusty pointed out, since this is just doing a sched() and the call
interrupt handler does not do anything other than send ack/eoi this
should not matter either. Which is good, and we only need to care for
the smp_call_function case.

>
>>
>> Iam not sure if this would be an easier solution, if we can acquire
the
>> call_lock, and tlb_state_lock before turning off the cpu from the
online
>> map, would that eliminate the ipi_map and the new active_map cases?
>
>Yes, taking call_lock will prevent stale call_function IPI on the dead
CPU.
>This will eliminate the need for ipi_map. However, active_map will
still
>be needed (since it is there to indicate offline-not-yet-dead CPUs
which
>may
>be running non-idle tasks and need to take smp_call_function IPIs and
>participate in RCU activity).

If the cpu is removed from the online map, why would there be stale rcu
activity for that cpu? I would think that the dead cpu is just in idle,
doesn't the rcu code also take a callback for cpu_dead? I thought the
current hotplug code already does this in moving all the tasklets and
the rcu code takes care of CPU_DEAD by handling them correctly.

Ideally when after calling __cpu_die(cpu), you could expect that the cpu
is really going to physically removed (in a platform that supports
that). If there is any chance that there could be some other piece of
code that could run on that cpu, then we probably should issue the
CPU_DEAD notification before the __cpu_die() is called

If the cpu does not need to participate in anything other than waiting
for a logical prepare online state, then we can assume that we don't
need a separate online_map and a active_map (which means almost dead?).
Removing the cpu_active and the ipi_map would make that code more
simpler.

>
>One concern with taking (call and tlb_state) locks before clearing
>from the active map was : today two, tomorrow more?
>

Seems like although we have 3 different IPI's the only one we are
concerned is CALL vector. Since already the smp_call_function
serializes, and hotplug being a not so often activity it makes sense to
acquire that lock before removing from the map, that would achieve the
same goals.

Cheers,
ashok