Hi Mel, > I haven't tested this patch yet but typically how I would test it is > multiple parallel instances of make func from libhugetlbfs. In > particular I would be looking out for counter corruption. Has > something like this been done? I know hugetlb_lock protects the > counters but the locking in there has turned into a bit of a mess so > it's easy to miss something. Thanks for the suggestion and sorry for taking so long. Make check has the same PASS/FAIL count before and after the patches. I also ran 16 copies of make func on a large box with 896 HW threads. Some of the tests that use shared memory were a bit upset, but that seems to be because we use a static key. It seems the tests were also fighting over the number of huge pages they wanted the system set to. It got up to a load average of 13207, and heap-overflow consumed all my memory, a pretty good effort considering I have over 1TB of it. After things settled down things were OK, apart from the fact that we have 20 huge pages unaccounted for: HugePages_Total: 10000 HugePages_Free: 9980 HugePages_Rsvd: 0 HugePages_Surp: 0 I verified there were no shared memory segments, and no files in the hugetlbfs filesystem (I double checked by unmounting it). I can't see how this patch set would cause this. It seems like we can leak huge pages, perhaps in an error path. Anyway, I'll repost the patch set for comments. Anton -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. 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>