Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752261AbbDDANk (ORCPT ); Fri, 3 Apr 2015 20:13:40 -0400 Received: from mga01.intel.com ([192.55.52.88]:57838 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751635AbbDDANi (ORCPT ); Fri, 3 Apr 2015 20:13:38 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,520,1422950400"; d="scan'208";a="703149670" Date: Fri, 3 Apr 2015 17:13:36 -0700 From: Jesse Brandeburg To: Ingo Molnar Cc: , Thomas Gleixner , , John Subject: Re: [PATCH] irq: revert non-working patch to affinity defaults Message-ID: <20150403171336.000075f2@unknown> In-Reply-To: <20150403065557.GA12815@gmail.com> References: <20150403005022.3143.73693.stgit@jbrandeb-cp2.jf.intel.com> <20150403065557.GA12815@gmail.com> X-Mailer: Claws Mail 3.7.10cvs7 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1537 Lines: 41 On Fri, 3 Apr 2015 08:55:57 +0200 Ingo Molnar wrote: > So the original commit also has the problem that it unnecessary > drops/retakes the descriptor lock: > > > irq_put_desc_unlock(desc, flags); > > - /* set the initial affinity to prevent every interrupt being on CPU0 */ > > - if (m) > > - __irq_set_affinity(irq, m, false); > > > i.e. why not just call into irq_set_affinity_locked() while we still > have the descriptor locked? I had tried that but it didn't help much. I also tried kzalloc a new descriptor like the proc functionality does, and that changes the behavior a little, but doesn't fix it AFAICS. > Now this is just a small annoyance that should not really matter - it > would be nice to figure out the real reason for why the irqs move back > to CPU#0. > > In theory the same could happen to 'irqbalanced' as well, if it calls > shortly after an irq was registered - so this is not a bug we want to > ignore. Let me know if I can do something to help, the IRQ code is a bit of a steep learning curve, so the chances of me fixing it are small. > Also, worst case we are back to where v3.19 was, right? So could we > try to analyze this a bit more? Yes, 3.19 shipped with this issue. Again, let me know if I can help. Thanks, Jesse -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/