[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100416153210.GG5162@nowhere>
Date: Fri, 16 Apr 2010 17:32:12 +0200
From: Frederic Weisbecker <fweisbec@...il.com>
To: Don Zickus <dzickus@...hat.com>
Cc: mingo@...e.hu, peterz@...radead.org, gorcunov@...il.com,
aris@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] [watchdog] combine nmi_watchdog and softlockup
On Fri, Apr 16, 2010 at 11:04:07AM -0400, Don Zickus wrote:
> > This is really just a corner case, I guess you don't need to
> > bother with that. It is actually racy against other cpus and adding
> > a spinlock here (in the everything is fine path) would be an overkill.
> >
> > In fact, having two per cpu vars named hardlockup_warned and
> > softlockup_warned would be better than cpumasks. I'm sorry I
> > suggested you the cpumask, but such per cpu vars will avoid
> > you dealing with these synchonization issues. And one of the primary
> > rules is usually to never take a lock from NMIs if we can :)
>
> Yeah, I guess per cpu is better. I agree that locks in NMI are frowned
> upon but I wasn't sure of it was dealt with.
They work in fact. They are just not checked by lockdep.
And mostly they are very dangerous: if something else can
take it (from interrupt, from context) then this is a deadlock.
And even though we ensure this is only taken from NMI, we tend
to avoid that.
> I'll try to implement this. Any objections if I combined hardlockup and
> softlockup with per cpu watchdog_warn and have bit masks for HARDLOCKUP
> and SOFTLOCKUP? I hate to just waste per cpu space for this.
Hmm, a hardlockup can come in after a softlockup.
Don't worry too much about memory: usually the more you have cpu,
the more you have memory :)
Plus this is debugging code, not something supposed to be enabled
in production.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists