From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933034Ab3GWOHb (ORCPT ); Tue, 23 Jul 2013 10:07:31 -0400 Received: from cantor2.suse.de ([195.135.220.15]:41989 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932442Ab3GWOHa (ORCPT ); Tue, 23 Jul 2013 10:07:30 -0400 Date: Tue, 23 Jul 2013 16:07:29 +0200 From: Michal Hocko To: Don Zickus Cc: linux-kernel@vger.kernel.org, Andrew Morton , Frederic Weisbecker , Thomas Gleixner , Ingo Molnar Subject: Re: [RFC -v3 2/2] watchdog: update watchdog_tresh properly Message-ID: <20130723140729.GH8677@dhcp22.suse.cz> References: <1374493502-31907-1-git-send-email-mhocko@suse.cz> <1374503566-2521-1-git-send-email-mhocko@suse.cz> <20130723135334.GF126784@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130723135334.GF126784@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 23-07-13 09:53:34, Don Zickus wrote: > On Mon, Jul 22, 2013 at 04:32:46PM +0200, Michal Hocko wrote: > > The nmi one is disabled and then reinitialized from scratch. This > > has an unpleasant side effect that the allocation of the new event might > > fail theoretically so the hard lockup detector would be disabled for > > such cpus. On the other hand such a memory allocation failure is very > > unlikely because the original event is deallocated right before. > > It would be much nicer if we just changed perf event period but there > > doesn't seem to be any API to do that right now. > > It is also unfortunate that perf_event_alloc uses GFP_KERNEL allocation > > unconditionally so we cannot use on_each_cpu() and do the same thing > > from the per-cpu context. The update from the current CPU should be > > safe because perf_event_disable removes the event atomically before > > it clears the per-cpu watchdog_ev so it cannot change anything under > > running handler feet. > > I guess I don't have a problem with this. I was hoping to have more > shared code with the regular stop/start routines but with the pmu bit > locking (to share pmus with oprofile), you really need to unregister > everything to stop the lockup detector. This makes it a little too heavy > for a restart routine like this. I am not sure I understand the above. Regular stop/start is about all the machinery, I have tried to reduce the restarting to bare minimum. Do you find the current version heavier than the full disable_all && enable_all? > The only odd thing is I can't figure out which version you were using to > apply this patch. I can't find old_thresh (though I understand the idea > of it). current Linus tree (linux-next - 20130723 - has it as well AFAICS) > Cheers, > Don -- Michal Hocko SUSE Labs