Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759493Ab0D3TN3 (ORCPT ); Fri, 30 Apr 2010 15:13:29 -0400 Received: from mga01.intel.com ([192.55.52.88]:54671 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759469Ab0D3TNF (ORCPT ); Fri, 30 Apr 2010 15:13:05 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.52,304,1270450800"; d="scan'208";a="794404677" Date: Fri, 30 Apr 2010 12:13:01 -0700 (Pacific Daylight Time) From: Peter P Waskiewicz Jr To: Thomas Gleixner cc: "davem@davemloft.net" , "arjan@linux.jf.intel.com" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH linux-next v2 1/2] irq: Add CPU mask affinity hint In-Reply-To: Message-ID: References: <20100430085150.4630.46790.stgit@ppwaskie-hc2.jf.intel.com> X-X-Sender: ppwaskie@imapmail.glb.intel.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1651 Lines: 42 On Fri, 30 Apr 2010, Thomas Gleixner wrote: > On Fri, 30 Apr 2010, Peter P Waskiewicz Jr wrote: >> On Fri, 30 Apr 2010, Thomas Gleixner wrote: >>>> +extern int irq_register_affinity_hint(unsigned int irq, >>>> + const struct cpumask *m); >>> >>> I think we can do with a single funtion irq_set_affinity_hint() and >>> let the caller set the pointer to NULL. >> >> Ok, I've been running into some issues. If CONFIG_CPUMASK_OFFSTACK is not >> set, then cpumask_var_t structs are single-element arrays that cannot be >> NULL'd out. I'm pretty sure I need to keep the unregister part of the API. >> Thoughts? > > extern int irq_set_affinity_hint(unsigned int irq, const struct cpumask *m); > > So why should calling irq_set_affinity_hint(irqnr, NULL) not work ? What was that you said about coffee and brain cells? :-) > >> I just looked at the original show_affinity function, and it does not grab >> desc->lock before copying mask out of desc. Should I follow that model, or >> should I fix that function to honor desc->lock? > > desc->affinity can only race against something changing the affinity > bits, so that just might return some random data. > > In the hint case the irq could be shut down and the affinity hint > could be freed while you are accessing it. Not a good idea :) Good point. Latest spin coming shortly. Thanks for the quick feedback! -PJ -- 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/