node affine NUMA scheduler extension
PATCH 1/1 node affine NUMA scheduler extension
No real change compared to the previous version, patch was only adapted to fit into 2.6.0-test1. I append the description from my previous posting.
The patch shows 5-8% gain in the numa_test benchmark on a TX7 Itanium2 machine with 8 CPUs/4 nodes. The interesting numbers are ElapsedTime and TotalUserTime. In numa_test I changed the PROBLEMSIZE from 1000000 to 2000000 in order to get longer execution/test times. The results are avergaes over 10 measurements, the standard deviation is in brackets.
2.6.0-test1 kernel: original NUMA scheduler
Tasks AverageUserTime ElapsedTime TotalUserTime TotalSysTime 4 52.67(3.51) 61.30(8.04) 210.70(14.05) 0.16(0.02) 8 50.29(1.85) 55.19(6.36) 402.38(14.78) 0.34(0.02) 16 53.27(2.30) 115.30(5.40) 852.40(36.75) 0.62(0.02)
32 51.92(1.13) 215.98(5.95) 1661.66(36.08) 1.21(0.04)
2.6.0-test1 kernel: node affine NUMA scheduler
Tasks AverageUserTime ElapsedTime TotalUserTime TotalSysTime 4 50.13(2.09) 56.72(8.46) 200.55(8.34) 0.15(0.01) 8 49.78(1.29) 54.43(4.90) 398.26(10.31) 0.34(0.02) 16 50.37(0.96) 110.79(8.46) 806.01(15.33) 0.63(0.03)
32 51.10(0.51) 210.18(3.27) 1635.40(16.16) 1.23(0.04)
In order to see the UserTime / CPU one needs an additional patch which gets back the per cpu times in /proc/pid/cpu. The patch comes in a separate post.
Quoted 22 lines
This patch is an adaptation of the earlier work on the node affine NUMA scheduler to the NUMA features meanwhile integrated into 2.5. Compared to the patch posted for 2.5.39 this one is much simpler and easier to understand.
The main idea is (still) that tasks are assigned a homenode to which they are preferentially scheduled. They are not only sticking as much as possible to a node (as in the current 2.5 NUMA scheduler) but will also be attracted back to their homenode if they had to be scheduled away. Therefore the tasks can be called "affine" to the homenode.
The implementation is straight forward:
- Tasks have an additional element in their task structure (node).
- The scheduler keeps track of the homenodes of the tasks running in each node and on each runqueue.
- At cross-node load balance time nodes/runqueues which run tasks originating from the stealer node are preferred. They get a weight bonus for each task with the homenode of the stealer.
- When stealing from a remote node one tries to get the own tasks (if any) or tasks from other nodes (if any). This way tasks are kept on their homenode as long as possible.
Quoted 5 lines
The selection of the homenode is currently done at initial load balancing, i.e. at
exec(). A smarter selection method might be needed for improving the situation for multithreaded processes. An option is thedynamic_homenodepatch I posted for 2.5.39 or some other scheme based on an RSS/node measure. But that's another story...
Regards,
Erich
include/linux/sched.h +5 -0
@@ -343,6 +343,9 @@ struct task_struct {unsigned long policy;unsigned long cpus_allowed;unsigned int time_slice, first_time_slice; +#ifdef CONFIG_NUMA +int node;/* homenode: task will be preferrentially scheduled on it */ +#endif struct list_head tasks;struct list_head ptrace_children;
@@ -499,9 +502,11 @@ static inline int set_cpus_allowed(task_#ifdef CONFIG_NUMA extern void sched_balance_exec (void );extern void node_nr_running_init (void ); +extern void set_task_node (task_t *p,int node);#else #define sched_balance_exec () {}#define node_nr_running_init () {} +#define set_task_node (p,n) {}#endif extern void set_user_nice (task_t *p,long nice);
kernel/sched.c +89 -14
216 lines not on this page · raw message