Re: frequent lockups in 3.18rc4: revert suggestion

[Fabian Frederick]

> On 16 November 2014 at 21:03 Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
> wrote:
>
>
> On Sun, Nov 16, 2014 at 12:33 AM, Fabian Frederick <fabf@xxxxxxxxx> wrote:
> >
> >Â Â Â Â ÂHave you tried reverting the following patches (all from rc1) ?
>
> Hmm. Any particular reason you're looking at those?
>
> >Â Â Â Â Âc6f4459 v3.18-rc1 smp: Add new wake_up_all_idle_cpus() function
> >Â Â Â Â Âbb964a9 v3.18-rc1 kernel misc: Replace __get_cpu_var uses
> >Â Â Â Â Â2ed903c v3.18-rc1 cpuidle: Use wake_up_all_idle_cpus() to wake up
> >all idle cpus
>
> It does strike me that the reschedule IPI is somewhat special in that
> we don't try to serialize it at all, on the grounds that a lost IPI is
> ok (ie smp_send_reschedule() is very much a special case of IPI). Or
> am I mis-remembering? Does that series end up adding a lot more of
> those things, rather than using the normal smp_call_function().
>
> The normal smp_function_mask() thing tries to make sure only one entry
> is ever active at a time (even a non-blocking one will use the whole
> "queue it on a llist, only send the IPI if the llist was empty", so
> this is not about the IPI's being synchronous). The rescheduling
> thing is rather special, isn't it.
>
> The softlockup thing *did* look like some IPI got lost. Could an IPI
> overflow on the RESCHEDULE_VECTOR end up affecting other vectors? It's
> been too long since I worked with the APIC (and by "too long", I
> obviously mean "thank God I haven't had to" ;^) but there used to be
> grouping of the vectors..
>
> Maybe that is all barking up the wrong tree, but I'm wondering why
> Fabian picked that particular set of commits. Fabian?

Thomas talked about csd_lock and the last reliable stack function
being smp_call_function_single, I thought it could be interesting
to bisect directly in smp.c as I only read about reverting mm/memory.c
stuff ... Maybe not too much original but who knows ? :)
Â
Regards,
Fabian

>
>Â Â Â Â Â Â Â Â Â Â Â Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/