[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.1004302038140.2951@localhost.localdomain>
Date: Fri, 30 Apr 2010 21:04:42 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@...el.com>
cc: "davem@...emloft.net" <davem@...emloft.net>,
"arjan@...ux.jf.intel.com" <arjan@...ux.jf.intel.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH linux-next v2 1/2] irq: Add CPU mask affinity hint
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 ?
> 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 :)
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists