On Wed, May 25, 2016 at 05:11:03PM -0400, neha agarwal wrote: > On Wed, May 25, 2016 at 4:03 PM, Kirill A. Shutemov <kirill@xxxxxxxxxxxxx> > wrote: > > > On Wed, May 25, 2016 at 03:11:55PM -0400, neha agarwal wrote: > > > Hi All, > > > > > > I have been testing Hugh's and Kirill's huge tmpfs patch sets with > > > Cassandra (NoSQL database). I am seeing significant performance gap > > between > > > these two implementations (~30%). Hugh's implementation performs better > > > than Kirill's implementation. I am surprised why I am seeing this > > > performance gap. Following is my test setup. > > > > Thanks for the report. I'll look into it. > > > > Thanks Kirill for looking into it. > > > > > Patchsets > > > ======== > > > - For Hugh's: > > > I checked out 4.6-rc3, applied Hugh's preliminary patches (01 to 10 > > > patches) from here: https://lkml.org/lkml/2016/4/5/792 and then applied > > the > > > THP patches posted on April 16 (01 to 29 patches). > > > > > > - For Kirill's: > > > I am using his branch "git:// > > > git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git hugetmpfs/v8", > > which > > > is based off of 4.6-rc3, posted on May 12. > > > > > > > > > Khugepaged settings > > > ================ > > > cd /sys/kernel/mm/transparent_hugepage > > > echo 10 >khugepaged/alloc_sleep_millisecs > > > echo 10 >khugepaged/scan_sleep_millisecs > > > echo 511 >khugepaged/max_ptes_none > > > > Do you make this for both setup? > > > > It's not really nessesary for Hugh's, but it makes sense to have this > > idenatical for testing. > > > > Yeah right, Hugh's will not be impacted by these settings but for identical > testing I did that. Could you try to drop this changes and leave khugepaged with defaults. One theory is that you just create additional load on the system without any gain. As pages wasn't swapped out we have nothing to collapse back, but scanning takes CPU time. Hugh didn't change khugepaged, so it would not need to look into tmpfs mapping to check if there's something to collapse... -- Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
