On Wed, May 25, 2016 at 5:21 PM, Kirill A. Shutemov <kirill@shutemov.name>
wrote:

> 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@shutemov.name>
> > 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.
>

With default khugepaged options also, the performance difference between
the two implementation remains as before.


> 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.
>

Since the performance difference is still there with default khugepaged
settings, probably khugepaged is not the culprit here.


>
> 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
>



-- 
Thanks and Regards,
Neha