On Thu, Feb 03, 2011 at 01:22:14PM -0800, David Rientjes wrote: > i.e. no global locking, but we've accepted the occassional off-by-one > error (even though splitting of hugepages isn't by any means lightning > fast and the overhead of atomic ops would be negligible). Agreed losing an increment is not a problem, but in very large systems it will become a bottleneck. It's not super urgent, but I think it needs to become a per-cpu counter sooner than later (not needed immediately but I would appreciate an incremental patch soon to address that). split_huge_page is already fully SMP scalable if the rmap isn't shared (i.e. fully SMP scalable across different execve) and I'd like it to stay that way because split_huge_page can run at high frequency at times from different processes, so in very large systems it may be measurable, with that cacheline bouncing around 1024 cpus. pages_collapsed is not a problem because it's only used by one kernel thread so it can't be contended. Again not super urgent but better to optimize it ;). -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>