From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 In-Reply-To: <20160525212129.GB15857@node.shutemov.name> References: <1463067672-134698-1-git-send-email-kirill.shutemov@linux.intel.com> <20160525200356.GA15857@node.shutemov.name> <20160525212129.GB15857@node.shutemov.name> From: neha agarwal Date: Fri, 27 May 2016 12:28:01 -0400 Message-ID: Subject: Re: [PATCHv8 00/32] THP-enabled tmpfs/shmem using compound pages To: "Kirill A. Shutemov" Cc: "Kirill A. Shutemov" , Hugh Dickins , Andrea Arcangeli , Andrew Morton , Dave Hansen , Vlastimil Babka , Christoph Lameter , Naoya Horiguchi , Jerome Marchand , Yang Shi , Sasha Levin , Andres Lagar-Cavilla , Ning Qu , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Content-Type: multipart/alternative; boundary=94eb2c08ad4a4de5e00533d566c1 Sender: owner-linux-mm@kvack.org List-ID: --94eb2c08ad4a4de5e00533d566c1 Content-Type: text/plain; charset=UTF-8 On Wed, May 25, 2016 at 5:21 PM, Kirill A. Shutemov 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 --94eb2c08ad4a4de5e00533d566c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, May 25, 2016 at 5:21 PM, Kirill A. Shutemov <<= a href=3D"mailto:kirill@shutemov.name" target=3D"_blank">kirill@shutemov.na= me> 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 p= atch sets with
> > > Cassandra (NoSQL database). I am seeing significant performa= nce gap
> > between
> > > these two implementations (~30%). Hugh's implementation = performs better
> > > than Kirill's implementation. I am surprised why I am se= eing this
> > > performance gap. Following is my test setup.
> >
> > Thanks for the report. I'll look into it.
> >
>
> Thanks Kirill for looking into it.
>
>
> > > Patchsets
> > > =3D=3D=3D=3D=3D=3D=3D=3D
> > > - For Hugh's:
> > > I checked out 4.6-rc3, applied Hugh's preliminary patche= s (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=C2=A0 "git://
> > > git.kernel.org/pub/scm/li= nux/kernel/git/kas/linux.git hugetmpfs/v8",
> > which
> > > is based off of 4.6-rc3, posted on May 12.
> > >
> > >
> > > Khugepaged settings
> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > 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 de= faults.
=C2=A0
With default khugepaged optio= ns also, the performance difference between the two implementation remains = as before.=C2=A0


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 perform= ance difference is still there with default khugepaged settings, probably k= hugepaged is not the culprit here.
=C2=A0

Hugh didn't change khugepaged, so it would not need to look into tmpfs<= br> mapping to check if there's something to collapse...

--
=C2=A0Kirill A. Shutemov



--
Thanks and Regards,
Neha
--94eb2c08ad4a4de5e00533d566c1-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org