diff mbox

pci/intr_remapping: allocate irq_iommu on node

Message ID 4A785C17.3030104@kernel.org (mailing list archive)
State Superseded, archived
Headers show

Commit Message

Yinghai Lu Aug. 4, 2009, 4:04 p.m. UTC 
make it use node from irq_desc.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 drivers/pci/intr_remapping.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Suresh Siddha Aug. 4, 2009, 5:19 p.m. UTC | #1 
On Tue, 2009-08-04 at 09:04 -0700, Yinghai Lu wrote:
> make it use node from irq_desc.
> 
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> 
> ---
>  drivers/pci/intr_remapping.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> Index: linux-2.6/drivers/pci/intr_remapping.c
> ===================================================================
> --- linux-2.6.orig/drivers/pci/intr_remapping.c
> +++ linux-2.6/drivers/pci/intr_remapping.c
> @@ -201,7 +201,7 @@ int alloc_irte(struct intel_iommu *iommu
>  	for (i = index; i < index + count; i++)
>  		table->base[i].present = 1;
>  
> -	irq_iommu = irq_2_iommu_alloc(irq);
> +	irq_iommu = irq_2_iommu_alloc_node(irq, irq_to_desc(irq)->node);

As far as I can see, this node will always be boot_cpu_id's node. We
allocate the IRTE at the time of the create_irq() and at that time,
desc->node will always be of the boot_cpu_id's.

Can you please elaborate when this node will be different to make this
an effective patch?

thanks,
suresh

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Yinghai Lu Aug. 5, 2009, 9:14 a.m. UTC | #2 
Suresh Siddha wrote:
> On Tue, 2009-08-04 at 09:04 -0700, Yinghai Lu wrote:
>> make it use node from irq_desc.
>>
>> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
>>
>> ---
>>  drivers/pci/intr_remapping.c |    4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> Index: linux-2.6/drivers/pci/intr_remapping.c
>> ===================================================================
>> --- linux-2.6.orig/drivers/pci/intr_remapping.c
>> +++ linux-2.6/drivers/pci/intr_remapping.c
>> @@ -201,7 +201,7 @@ int alloc_irte(struct intel_iommu *iommu
>>  	for (i = index; i < index + count; i++)
>>  		table->base[i].present = 1;
>>  
>> -	irq_iommu = irq_2_iommu_alloc(irq);
>> +	irq_iommu = irq_2_iommu_alloc_node(irq, irq_to_desc(irq)->node);
> 
> As far as I can see, this node will always be boot_cpu_id's node. We
> allocate the IRTE at the time of the create_irq() and at that time,
> desc->node will always be of the boot_cpu_id's.
> 
> Can you please elaborate when this node will be different to make this
> an effective patch?

without this patch

[  299.175436] igbvf 0000:41:10.0: enabling device (0000 -> 0002)
[  299.180009] igbvf 0000:41:10.0: using 64bit DMA mask
[  299.183077] igbvf 0000:41:10.0: using 64bit consistent DMA mask
[  299.199870] igbvf 0000:41:10.0: enabling bus mastering
[  299.205534] igbvf 0000:41:10.0: setting latency timer to 64
[  299.219654] reserve_memtype added 0xcfc00000-0xcfc04000, track uncached-minus, req uncached-minus, ret uncached-minus
[  299.239615] reserve_memtype added 0xcfc20000-0xcfc21000, track uncached-minus, req uncached-minus, ret uncached-minus
[  299.260181]   alloc irq_desc for 217 on node 2
[  299.263501]   alloc kstat_irqs on node 2
[  299.276276] alloc irq_2_iommu on node 0
[  299.281847] igbvf 0000:41:10.0: irq 217 for MSI/MSI-X
[  299.285511]   alloc irq_desc for 218 on node 2
[  299.297813]   alloc kstat_irqs on node 2
[  299.302543] alloc irq_2_iommu on node 0
[  299.315358] igbvf 0000:41:10.0: irq 218 for MSI/MSI-X
[  299.321102]   alloc irq_desc for 219 on node 2
[  299.325932]   alloc kstat_irqs on node 2
[  299.338616] alloc irq_2_iommu on node 0
[  299.340789] igbvf 0000:41:10.0: irq 219 for MSI/MSI-X
[  299.356532] igbvf 0000:41:10.0: PF still in reset state, assigning new address
[  299.365128] igbvf 0000:41:10.0: PF still resetting
[  299.377625] igbvf 0000:41:10.0: Intel(R) 82576 Virtual Function
[  299.385619] igbvf 0000:41:10.0: Address: c6:e3:de:62:de:eb
[  299.395957] igbvf 0000:41:10.0: MAC: 1

thought we could put irq_2_iommu to same node too.

YH
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Suresh Siddha Aug. 6, 2009, 12:36 a.m. UTC | #3 
On Wed, 2009-08-05 at 02:14 -0700, Yinghai Lu wrote:
> without this patch
> 
> [  299.175436] igbvf 0000:41:10.0: enabling device (0000 -> 0002)
> [  299.180009] igbvf 0000:41:10.0: using 64bit DMA mask
> [  299.183077] igbvf 0000:41:10.0: using 64bit consistent DMA mask
> [  299.199870] igbvf 0000:41:10.0: enabling bus mastering
> [  299.205534] igbvf 0000:41:10.0: setting latency timer to 64
> [  299.219654] reserve_memtype added 0xcfc00000-0xcfc04000, track uncached-minus, req uncached-minus, ret uncached-minus
> [  299.239615] reserve_memtype added 0xcfc20000-0xcfc21000, track uncached-minus, req uncached-minus, ret uncached-minus
> [  299.260181]   alloc irq_desc for 217 on node 2
> [  299.263501]   alloc kstat_irqs on node 2
> [  299.276276] alloc irq_2_iommu on node 0
> [  299.281847] igbvf 0000:41:10.0: irq 217 for MSI/MSI-X
> [  299.285511]   alloc irq_desc for 218 on node 2
> [  299.297813]   alloc kstat_irqs on node 2
> [  299.302543] alloc irq_2_iommu on node 0
> [  299.315358] igbvf 0000:41:10.0: irq 218 for MSI/MSI-X
> [  299.321102]   alloc irq_desc for 219 on node 2
> [  299.325932]   alloc kstat_irqs on node 2
> [  299.338616] alloc irq_2_iommu on node 0
> [  299.340789] igbvf 0000:41:10.0: irq 219 for MSI/MSI-X
> [  299.356532] igbvf 0000:41:10.0: PF still in reset state, assigning new address
> [  299.365128] igbvf 0000:41:10.0: PF still resetting
> [  299.377625] igbvf 0000:41:10.0: Intel(R) 82576 Virtual Function
> [  299.385619] igbvf 0000:41:10.0: Address: c6:e3:de:62:de:eb
> [  299.395957] igbvf 0000:41:10.0: MAC: 1
> 
> thought we could put irq_2_iommu to same node too.

Yinghai, even with this patch, we will still be allocating from node-0.
No?

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Yinghai Lu Aug. 6, 2009, 1:19 a.m. UTC | #4 
Suresh Siddha wrote:
> On Wed, 2009-08-05 at 02:14 -0700, Yinghai Lu wrote:
>> without this patch
>>
>> [  299.175436] igbvf 0000:41:10.0: enabling device (0000 -> 0002)
>> [  299.180009] igbvf 0000:41:10.0: using 64bit DMA mask
>> [  299.183077] igbvf 0000:41:10.0: using 64bit consistent DMA mask
>> [  299.199870] igbvf 0000:41:10.0: enabling bus mastering
>> [  299.205534] igbvf 0000:41:10.0: setting latency timer to 64
>> [  299.219654] reserve_memtype added 0xcfc00000-0xcfc04000, track uncached-minus, req uncached-minus, ret uncached-minus
>> [  299.239615] reserve_memtype added 0xcfc20000-0xcfc21000, track uncached-minus, req uncached-minus, ret uncached-minus
>> [  299.260181]   alloc irq_desc for 217 on node 2
>> [  299.263501]   alloc kstat_irqs on node 2
>> [  299.276276] alloc irq_2_iommu on node 0
>> [  299.281847] igbvf 0000:41:10.0: irq 217 for MSI/MSI-X
>> [  299.285511]   alloc irq_desc for 218 on node 2
>> [  299.297813]   alloc kstat_irqs on node 2
>> [  299.302543] alloc irq_2_iommu on node 0
>> [  299.315358] igbvf 0000:41:10.0: irq 218 for MSI/MSI-X
>> [  299.321102]   alloc irq_desc for 219 on node 2
>> [  299.325932]   alloc kstat_irqs on node 2
>> [  299.338616] alloc irq_2_iommu on node 0
>> [  299.340789] igbvf 0000:41:10.0: irq 219 for MSI/MSI-X
>> [  299.356532] igbvf 0000:41:10.0: PF still in reset state, assigning new address
>> [  299.365128] igbvf 0000:41:10.0: PF still resetting
>> [  299.377625] igbvf 0000:41:10.0: Intel(R) 82576 Virtual Function
>> [  299.385619] igbvf 0000:41:10.0: Address: c6:e3:de:62:de:eb
>> [  299.395957] igbvf 0000:41:10.0: MAC: 1
>>
>> thought we could put irq_2_iommu to same node too.
> 
> Yinghai, even with this patch, we will still be allocating from node-0.
> No?

with this patch will get 
alloc irq_2_iommu on node 2

YH
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Suresh Siddha Aug. 6, 2009, 7:16 p.m. UTC | #5 
On Wed, 2009-08-05 at 18:19 -0700, Yinghai Lu wrote:
> Suresh Siddha wrote:
> > 
> > Yinghai, even with this patch, we will still be allocating from node-0.
> > No?
> 
> with this patch will get 
> alloc irq_2_iommu on node 2

Looking closer, I missed the fact that we are now using the
create_irq_nr() which has the node information.

Acked-by: Suresh Siddha <suresh.b.siddha@intel.com>

Thanks.

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

Index: linux-2.6/drivers/pci/intr_remapping.c
===================================================================
--- linux-2.6.orig/drivers/pci/intr_remapping.c
+++ linux-2.6/drivers/pci/intr_remapping.c
@@ -201,7 +201,7 @@  int alloc_irte(struct intel_iommu *iommu
 	for (i = index; i < index + count; i++)
 		table->base[i].present = 1;
 
-	irq_iommu = irq_2_iommu_alloc(irq);
+	irq_iommu = irq_2_iommu_alloc_node(irq, irq_to_desc(irq)->node);
 	if (!irq_iommu) {
 		spin_unlock_irqrestore(&irq_2_ir_lock, flags);
 		printk(KERN_ERR "can't allocate irq_2_iommu\n");
@@ -255,7 +255,7 @@  int set_irte_irq(int irq, struct intel_i
 
 	spin_lock_irqsave(&irq_2_ir_lock, flags);
 
-	irq_iommu = irq_2_iommu_alloc(irq);
+	irq_iommu = irq_2_iommu_alloc_node(irq, irq_to_desc(irq)->node);
 
 	if (!irq_iommu) {
 		spin_unlock_irqrestore(&irq_2_ir_lock, flags);