Hello, On Tue, Feb 08, 2011 at 09:54:34AM -0800, Dave Hansen wrote: > Just FYI, I did some profiling on a workload that constantly split and > joined pages. Very little of the overhead was in the scanning itself, > so I think you're dead-on here. Yep, my way to deduce it has been to set both to 100%, and check the rate of increase of /sys/kernel/mm/transparent_hugepage/khugepaged/full_scans vs /sys/kernel/mm/ksm/full_scans and the differences is enormous. So a 100% CPU ksmd scan can probably be followed more than well with a 1% CPU khugepaged scan and probably achieve the exact same hugepage ratio of a 100% khugepaged scan. The default khugepaged scan is super paranoid (it has to be, considering the default ksm scan is zero). Maybe we can still increase the default pages_to_scan a bit. I suspect most of the current cost should be in the scheduler and that only accounts for 1 kthread schedule event every 10 sec. -- 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>