Skip to contentSkip to conversation

Run PCI driver initialization on local node

PATCH In review Andi Kleen 2 participants 11 messages Jul 6, 2005 – Jul 7, 2005

Subsystems (3)
Memory management PCI MM NUMA placement
lore
Share & tools
lore

Andi Kleen

author
#0 lore raw

PATCH 1/1 Run PCI driver initialization on local node

Run PCI driver initialization on local node

Instead of adding messy kmalloc_node()s everywhere run the PCI driver probe on the node local to the device. Then the normal NUMA aware allocators do the right thing.

This would not have helped for IDE, but should for other more clean drivers that do more initialization in probe(). It won't help for drivers that do most of the work
on first open (like many network drivers)

Signed-off-by Andi Kleen <[email protected]>
cc [email protected]
drivers/pci/pci-driver.c +22 -1
Index: linux/drivers/pci/pci-driver.c
===================================================================
@@ -167,6 +167,27 @@ const struct pci_device_id *pci_match_de
 	return NULL;
 }
 
+static int pci_call_probe(struct pci_driver *drv, struct pci_dev *dev, 
+			  const struct pci_device_id *id)
+{
+	int error;
+#ifdef CONFIG_NUMA
+	/* Execute driver initialization on node where the 
+	   device's bus is attached to.  This way the driver likely
+	   allocates its local memory on the right node without
+	   any need to change it. */
+	cpumask_t oldmask = current->cpus_allowed;
+	int node = pcibus_to_node(dev->bus);
+	if (node >= 0 && node_online(node))
+	    set_cpus_allowed(current, node_to_cpumask(node));	
+#endif
+	error = drv->probe(dev, id);
+#ifdef CONFIG_NUMA
+	set_cpus_allowed(current, oldmask);
+#endif
+	return error;
+}
+
 /**
  * __pci_device_probe()
  * 

@@ -184,7 +205,7 @@ __pci_device_probe(struct pci_driver *dr
 
 		id = pci_match_device(drv, pci_dev);
 		if (id)
-			error = drv->probe(pci_dev, id);
+			error = pci_call_probe(drv, pci_dev, id);
 		if (error >= 0) {
 			pci_dev->driver = drv;
 			error = 0;
#1 lore raw
Quoted 3 lines · Andi Kleen

Instead of adding messy kmalloc_node()s everywhere run the PCI driver probe on the node local to the device. Then the normal NUMA aware allocators do the right thing.

That depends on the architecture. Some do round robin allocs for periods of time during bootup. I think it is better to explicitly place control structures.

author
#2 lore raw
Quoted 8 lines · Christoph Lameter
Quoted 3 lines · Andi Kleen

Instead of adding messy kmalloc_node()s everywhere run the PCI driver probe on the node local to the device. Then the normal NUMA aware allocators do the right thing.

That depends on the architecture. Some do round robin allocs for periods of time during bootup. I think it is better to explicitly place control

slab will usually do the right thing because it has a forced local node policy, but __gfp might not.
I agree it would be better to force the policy.

I kept the scheduling to CPU because slab still needs it.

Updated patch appended.

Quoted 1 line

structures.

Patching every driver in existence? That sounds like a lot of work.

The node local placement should be correct for nearly all drivers. I didn't see any other fancy placement in your patches. If a driver still wants to do fancy placement it is free to overwrite the policy. Having a good default is good.

Greg, please consider applying.

-Andi

Run PCI driver initialization on local node

Instead of adding messy kmalloc_node()s everywhere run the PCI driver probe on the node local to the device.

This would not have helped for IDE, but should for other more clean drivers that do more initialization in probe(). It won't help for drivers that do most of the work
on first open (like many network drivers)

Signed-off-by Andi Kleen <[email protected]>
cc [email protected]
drivers/pci/pci-driver.c +30 -1
Index: linux/drivers/pci/pci-driver.c
===================================================================
@@ -7,6 +7,7 @@
 #include <linux/module.h>
 #include <linux/init.h>
 #include <linux/device.h>
+#include <linux/mempolicy.h>
 #include "pci.h"
 
 /*

@@ -167,6 +168,34 @@ const struct pci_device_id *pci_match_de
 	return NULL;
 }
 
+static int pci_call_probe(struct pci_driver *drv, struct pci_dev *dev, 
+			  const struct pci_device_id *id)
+{
+	int error;
+#ifdef CONFIG_NUMA
+	/* Execute driver initialization on node where the 
+	   device's bus is attached to.  This way the driver likely
+	   allocates its local memory on the right node without
+	   any need to change it. */
+	struct mempolicy *oldpol; 
+	cpumask_t oldmask = current->cpus_allowed;
+	int node = pcibus_to_node(dev->bus);
+	if (node >= 0 && node_online(node))
+	    set_cpus_allowed(current, node_to_cpumask(node));	
+	/* And set default memory allocation policy */
+	oldpol = current->mempolicy;
+	current->mempolicy = &default_policy;
+	mpol_get(current->mempolicy);
+#endif
+	error = drv->probe(dev, id);
+#ifdef CONFIG_NUMA
+	set_cpus_allowed(current, oldmask);
+	mpol_free(current->mempolicy);
+	current->mempolicy = oldpol;
+#endif
+	return error;
+}
+
 /**
  * __pci_device_probe()
  * 

@@ -184,7 +213,7 @@ __pci_device_probe(struct pci_driver *dr
 
 		id = pci_match_device(drv, pci_dev);
 		if (id)
-			error = drv->probe(pci_dev, id);
+			error = pci_call_probe(drv, pci_dev, id);
 		if (error >= 0) {
 			pci_dev->driver = drv;
 			error = 0;
mm/mempolicy.c +1 -1
Index: linux/mm/mempolicy.c
===================================================================
@@ -88,7 +88,7 @@ static kmem_cache_t *sn_cache;
    policied. */
 static int policy_zone;
 
-static struct mempolicy default_policy = {
+struct mempolicy default_policy = {
 	.refcnt = ATOMIC_INIT(1), /* never free it */
 	.policy = MPOL_DEFAULT,
 };
include/linux/mempolicy.h +1 -0
Index: linux/include/linux/mempolicy.h
===================================================================
@@ -152,6 +152,7 @@ struct mempolicy *mpol_shared_policy_loo
 
 extern void numa_default_policy(void);
 extern void numa_policy_init(void);
+extern struct mempolicy default_policy;
 
 #else
#3 lore raw
Quoted 5 lines · Andi Kleen
Quoted 2 lines

That depends on the architecture. Some do round robin allocs for periods of time during bootup. I think it is better to explicitly place control

slab will usually do the right thing because it has a forced local node policy, but __gfp might not.

The slab allocator will do the right thing with the numa slab allocator in Andrew's tree but not with the one in Linus'tree. The one is Linus tree will just pickup whatever slab is available irregardless of the node. Only kmalloc_node will make a reasonable attempt to locate the memory on a specific node.

author
#4 lore raw
Quoted 11 lines · Christoph Lameter
Quoted 5 lines · Andi Kleen
Quoted 2 lines

That depends on the architecture. Some do round robin allocs for periods of time during bootup. I think it is better to explicitly place control

slab will usually do the right thing because it has a forced local node policy, but __gfp might not.

The slab allocator will do the right thing with the numa slab allocator in Andrew's tree but not with the one in Linus'tree. The one is Linus tree will just pickup whatever slab is available irregardless of the node.

It should usually do the right thing because it
runs on the correct CPUs. The only case that doesn't work is freeing on different CPUs than it was allocated, but hopefully that is not too common during system startup.

And then at some point NUMA aware slab will make it into mainline I guess.

Quoted 2 lines

Only kmalloc_node will make a reasonable attempt to locate the memory on a specific node.

You forgot __get_free_pages.

-Andi

#5 lore raw
Quoted 8 lines · Andi Kleen
Quoted 3 lines

The slab allocator will do the right thing with the numa slab allocator in Andrew's tree but not with the one in Linus'tree. The one is Linus tree will just pickup whatever slab is available irregardless of the node.

It should usually do the right thing because it
runs on the correct CPUs. The only case that doesn't work is freeing on different CPUs than it was allocated, but hopefully that is not too common during system startup.

The current slab wont do that unless you allocate enough entries so that a new page is retrieved from the page allocator. Then you may have local memory from the slab (if the memory policy is not on round robin).

If you allocate some slab entries on one node then you typically have a partially used page from that node. If you then switch to a different processor on a different node and then use the slab allocator to get an entry for that slab then that partially used page will be used! The slab allocator will return an entry from the *prior* node.

Quoted 1 line

And then at some point NUMA aware slab will make it into mainline > I guess.

Hopefully.

Quoted 4 lines
Quoted 2 lines

Only kmalloc_node will make a reasonable attempt to locate the memory on a specific node.

You forgot __get_free_pages.

The slab allocator uses alloc_pages and alloc_pages_node

author
#6 lore raw
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines

Only kmalloc_node will make a reasonable attempt to locate the memory on a specific node.

You forgot __get_free_pages.

The slab allocator uses alloc_pages and alloc_pages_node

alloc_pages is NUMA aware. __get_free_pages is just a wrapper for it.

-Andi

#7 lore raw
In reply to Andi Kleen
Quoted 7 lines · Andi Kleen
Quoted 6 lines · Christoph Lameter
Quoted 3 lines · Andi Kleen

Instead of adding messy kmalloc_node()s everywhere run the PCI driver probe on the node local to the device. Then the normal NUMA aware allocators do the right thing.

Quoted 5 lines
Quoted 2 lines

That depends on the architecture. Some do round robin allocs for periods of time during bootup. I think it is better to explicitly place control

slab will usually do the right thing because it has a forced local node policy, but __gfp might not.

GFP allocs may not do the right thing. If you want to do this then it may be best to set the memory policy to restrict allocations to the node on which the device resides.

Plus there are CPU less nodes. What happens to those?

Quoted 2 lines

Patching every driver in existence? That sounds like a lot of work.

No just patch those that would benefit from it. The existing dma_alloc_coherent already takes care of many of the placement issues for driver memory. We would probably need to patch more locations where higher level control structure allocations are being done.

Quoted 4 lines

The node local placement should be correct for nearly all drivers. I didn't see any other fancy placement in your patches. If a driver still wants to do fancy placement it is free to overwrite the policy. Having a good default is good.

Definitely.

author
#8 lore raw
Quoted 12 lines · Christoph Lameter
Quoted 10 lines · Andi Kleen
Quoted 8 lines · Christoph Lameter
Quoted 3 lines · Andi Kleen

Instead of adding messy kmalloc_node()s everywhere run the PCI driver probe on the node local to the device. Then the normal NUMA aware allocators do the right thing.

That depends on the architecture. Some do round robin allocs for periods of time during bootup. I think it is better to explicitly place control

Quoted 6 lines
Quoted 2 lines

slab will usually do the right thing because it has a forced local node policy, but __gfp might not.

GFP allocs may not do the right thing. If you want to do this then it may be best to set the memory policy to restrict allocations to the node on which the device resides.

They will do the right thing. Under memory pressue on the node it is better to back off than to fail.

Quoted 2 lines

Plus there are CPU less nodes. What happens to those?

They are not worse off that they are now.

Quoted 5 lines
Quoted 3 lines

Patching every driver in existence? That sounds like a lot of work.

No just patch those that would benefit from it. The existing

This would be "all devices that SGI ships on Altixes" ?

IMHO all can benefit.

-Andi

#9 lore raw
Quoted 6 lines · Andi Kleen
Quoted 3 lines

GFP allocs may not do the right thing. If you want to do this then it may be best to set the memory policy to restrict allocations to the node on which the device resides.

They will do the right thing. Under memory pressue on the node it is better to back off than to fail.

Node specific allocs fall back to other nodes and will not fail unless there is no memory available.

#10 lore raw
In reply to Andi Kleen
Quoted 6 lines · Andi Kleen
Quoted 4 lines
Quoted 2 lines

Patching every driver in existence? That sounds like a lot of work.

No just patch those that would benefit from it. The existing

This would be "all devices that SGI ships on Altixes" ?

Anyone can patch devices drivers. High performance drivers suffer the most from wrong node placement. These are most likely 10G ethernet, high speed scsi etc.

The main concern at this point are the higher abstraction layers. These are generic and if they do the right thing then we have already come a long way.

Quoted 1 line

IMHO all can benefit.

Absolutely.