Messages in this thread | | | Date | Tue, 13 Dec 2005 19:54:57 -0800 | From | Paul Jackson <> | Subject | Re: [PATCH] Cpuset: rcu optimization of page alloc hook |
| |
pj wrote: > Time for me to learn more about rcu.
Well, that was easy.
Directly using RCU to guard that task->cpuset pointer instead of cheating via the RCU hooks in the slab cache was just a few lines of code.
But, boy oh boy, that synchronize_rcu() call sure takes it time.
My cpuset torture test was creating, destroying and abusing about 2600 cpusets/sec before this change, and now it does about 144 cpusets/sec.
That cost 95% of the performance. This only hits on the cost of attaching a task to a different cpuset (by writing its <pid> to some other cpuset 'tasks' file.)
Just commenting out the synchronize_cpu() restores the previous speed.
Nothing surprising here - this is just how rcu claims it behaves, heavily favoring the read side performance. These delays are waiting for the other cpus doing rcu_read_lock() to go through a quite period (reschedule, idle or return to user code).
Patches coming soon, to remove the cpuset_cache slab cache, and to use RCU directly instead.
Thanks, Eric.
-- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |