From: Yong Zhang <yong.zhang0@gmail.com> To: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "arjan@linux.jf.intel.com" <arjan@linux.jf.intel.com>, "davem@davemloft.net" <davem@davemloft.net>, "netdev@vger.kernel.org" <netdev@vger.kernel.org> Subject: Re: [PATCH] irq: Add node_affinity CPU masks for smarter irqbalance hints Date: Tue, 24 Nov 2009 13:17:50 +0800 [thread overview] Message-ID: <2674af740911232117l275e933yaca3f1b8c1207bce@mail.gmail.com> (raw) In-Reply-To: <1258968980.2697.9.camel@ppwaskie-mobl2> [snip] >> >> 1) I think you should consider CONFIG_CPUMASK_OFFSTACK which will affect >> node_affinity. >> 2) It seems like this patch can't work with SPARSE_IRQ. > > This mechanism isn't going to be used by any internal kernel mechanism > for determining interrupt placement or operation. It's purely something > that either a driver can modify, or external script (through /proc), > that irqbalance will make use of. If irqbalance isn't running, or the > current version of irqbalance doesn't support reading node_affinity, > then it won't affect the system's operation. > > If irqbalance does support it, it'll read whatever the supplied mask is, > and then will try and balance interrupts within that mask. It will bail > if the mask is invalid, or won't apply to the running system, just like > how putting a bogus mask into smp_affinity is ignored. > > If there's something I'm missing beyond this with the two suggestions > you've made (I looked into those two parameters and tried to draw > conclusions), please let me know. My two suggestions are both about your adding node_affinity. Before you can use this element, you must initialise it firstly. You can refer how irq_desc::affinity is used in function alloc_desc_masks(). include/linux/irq.h: static inline bool alloc_desc_masks(struct irq_desc *desc, int node, bool boot) { gfp_t gfp = GFP_ATOMIC; if (boot) gfp = GFP_NOWAIT; #ifdef CONFIG_CPUMASK_OFFSTACK if (!alloc_cpumask_var_node(&desc->affinity, gfp, node)) return false; #ifdef CONFIG_GENERIC_PENDING_IRQ if (!alloc_cpumask_var_node(&desc->pending_mask, gfp, node)) { free_cpumask_var(desc->affinity); return false; } #endif #endif return true; } Thanks, Yong > > Cheers, > -PJ Waskiewicz > >
WARNING: multiple messages have this Message-ID (diff)
From: Yong Zhang <yong.zhang0@gmail.com> To: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "arjan@linux.jf.intel.com" <arjan@linux.jf.intel.com>, "davem@davemloft.net" <davem@davemloft.net>, "netdev@vger.kernel.org" <netdev@vger.kernel.org> Subject: Re: [PATCH] irq: Add node_affinity CPU masks for smarter irqbalance hints Date: Tue, 24 Nov 2009 13:17:50 +0800 [thread overview] Message-ID: <2674af740911232117l275e933yaca3f1b8c1207bce@mail.gmail.com> (raw) In-Reply-To: <1258968980.2697.9.camel@ppwaskie-mobl2> [snip] >> >> 1) I think you should consider CONFIG_CPUMASK_OFFSTACK which will affect >> node_affinity. >> 2) It seems like this patch can't work with SPARSE_IRQ. > > This mechanism isn't going to be used by any internal kernel mechanism > for determining interrupt placement or operation. It's purely something > that either a driver can modify, or external script (through /proc), > that irqbalance will make use of. If irqbalance isn't running, or the > current version of irqbalance doesn't support reading node_affinity, > then it won't affect the system's operation. > > If irqbalance does support it, it'll read whatever the supplied mask is, > and then will try and balance interrupts within that mask. It will bail > if the mask is invalid, or won't apply to the running system, just like > how putting a bogus mask into smp_affinity is ignored. > > If there's something I'm missing beyond this with the two suggestions > you've made (I looked into those two parameters and tried to draw > conclusions), please let me know. My two suggestions are both about your adding node_affinity. Before you can use this element, you must initialise it firstly. You can refer how irq_desc::affinity is used in function alloc_desc_masks(). include/linux/irq.h: static inline bool alloc_desc_masks(struct irq_desc *desc, int node, bool boot) { gfp_t gfp = GFP_ATOMIC; if (boot) gfp = GFP_NOWAIT; #ifdef CONFIG_CPUMASK_OFFSTACK if (!alloc_cpumask_var_node(&desc->affinity, gfp, node)) return false; #ifdef CONFIG_GENERIC_PENDING_IRQ if (!alloc_cpumask_var_node(&desc->pending_mask, gfp, node)) { free_cpumask_var(desc->affinity); return false; } #endif #endif return true; } Thanks, Yong > > Cheers, > -PJ Waskiewicz > >
next prev parent reply other threads:[~2009-11-24 5:17 UTC|newest] Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-11-23 6:46 [PATCH] irq: Add node_affinity CPU masks for smarter irqbalance hints Peter P Waskiewicz Jr 2009-11-23 7:32 ` Yong Zhang 2009-11-23 7:32 ` Yong Zhang 2009-11-23 9:36 ` Peter P Waskiewicz Jr 2009-11-23 10:21 ` ixgbe question Eric Dumazet 2009-11-23 10:30 ` Badalian Vyacheslav 2009-11-23 10:34 ` Waskiewicz Jr, Peter P 2009-11-23 10:37 ` Eric Dumazet 2009-11-23 14:05 ` Eric Dumazet 2009-11-23 21:26 ` David Miller 2009-11-23 14:10 ` Jesper Dangaard Brouer 2009-11-23 14:38 ` Eric Dumazet 2009-11-23 18:30 ` robert 2009-11-23 16:59 ` Eric Dumazet 2009-11-23 20:54 ` robert 2009-11-23 21:28 ` David Miller 2009-11-23 22:14 ` Robert Olsson 2009-11-23 23:28 ` Waskiewicz Jr, Peter P 2009-11-23 23:44 ` David Miller 2009-11-24 7:46 ` Eric Dumazet 2009-11-24 8:46 ` Badalian Vyacheslav 2009-11-24 9:07 ` Peter P Waskiewicz Jr 2009-11-24 9:55 ` Eric Dumazet 2009-11-24 10:06 ` Peter P Waskiewicz Jr 2009-11-24 11:37 ` [PATCH net-next-2.6] ixgbe: Fix TX stats accounting Eric Dumazet 2009-11-24 13:23 ` Eric Dumazet 2009-11-25 7:38 ` Jeff Kirsher 2009-11-25 9:31 ` Eric Dumazet 2009-11-25 9:38 ` Jeff Kirsher 2009-11-24 13:14 ` ixgbe question John Fastabend 2009-11-29 8:18 ` David Miller 2009-11-30 13:02 ` Eric Dumazet 2009-11-30 20:20 ` John Fastabend 2009-11-26 14:10 ` Badalian Vyacheslav 2009-11-23 17:05 ` [PATCH] irq: Add node_affinity CPU masks for smarter irqbalance hints Peter Zijlstra 2009-11-23 23:32 ` Waskiewicz Jr, Peter P 2009-11-24 8:38 ` Peter Zijlstra 2009-11-24 8:59 ` Peter P Waskiewicz Jr 2009-11-24 9:08 ` Peter Zijlstra 2009-11-24 9:15 ` Peter P Waskiewicz Jr 2009-11-24 14:43 ` Arjan van de Ven 2009-11-24 9:15 ` Peter Zijlstra 2009-11-24 10:07 ` Thomas Gleixner 2009-11-24 17:55 ` Peter P Waskiewicz Jr 2009-11-25 11:18 ` Peter Zijlstra 2009-11-24 6:07 ` Arjan van de Ven 2009-11-24 8:39 ` Peter Zijlstra 2009-11-24 14:42 ` Arjan van de Ven 2009-11-24 17:39 ` David Miller 2009-11-24 17:56 ` Peter P Waskiewicz Jr 2009-11-24 18:26 ` Eric Dumazet 2009-11-24 18:33 ` Peter P Waskiewicz Jr 2009-11-24 19:01 ` Eric Dumazet 2009-11-24 19:53 ` Peter P Waskiewicz Jr 2009-11-24 18:54 ` David Miller 2009-11-24 18:58 ` Eric Dumazet 2009-11-24 20:35 ` Andi Kleen 2009-11-24 20:46 ` Eric Dumazet 2009-11-25 10:30 ` Eric Dumazet 2009-11-25 10:37 ` Andi Kleen 2009-11-25 11:35 ` Eric Dumazet 2009-11-25 11:50 ` Andi Kleen 2009-11-26 11:43 ` Eric Dumazet 2009-11-24 5:17 ` Yong Zhang [this message] 2009-11-24 5:17 ` Yong Zhang 2009-11-24 8:39 ` Peter P Waskiewicz Jr 2009-11-23 7:12 Peter P Waskiewicz Jr
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=2674af740911232117l275e933yaca3f1b8c1207bce@mail.gmail.com \ --to=yong.zhang0@gmail.com \ --cc=arjan@linux.jf.intel.com \ --cc=davem@davemloft.net \ --cc=linux-kernel@vger.kernel.org \ --cc=netdev@vger.kernel.org \ --cc=peter.p.waskiewicz.jr@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.