From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932307AbcHKFqd (ORCPT ); Thu, 11 Aug 2016 01:46:33 -0400 Received: from mailout2.samsung.com ([203.254.224.25]:44506 "EHLO mailout2.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932155AbcHKFqa convert rfc822-to-8bit (ORCPT ); Thu, 11 Aug 2016 01:46:30 -0400 X-AuditID: b6c32a16-f79066d00000256b-6e-57ac113269f4 From: PINTU KUMAR To: "'vinayak menon'" Cc: "'Pavel Machek'" , "'Konstantin Khlebnikov'" , "'Minchan Kim'" , linux-kernel@vger.kernel.org, linux-mm@kvack.org, jaejoon.seo@samsung.com, jy0.jeon@samsung.com, vishnu.ps@samsung.com, chulspro.kim@samsung.com In-reply-to: Subject: RE: [linux-mm] Drastic increase in application memory usage with Kernel version upgrade Date: Thu, 11 Aug 2016 11:15:41 +0530 Message-id: <000801d1f393$a89627d0$f9c27770$@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8BIT X-Mailer: Microsoft Outlook 14.0 Thread-index: AQIXVAHQaum/ZHq6w8tgVkUeUnFZygHaOt8xAcd6opkBobdAEwGAZwgIAmAkU+gCuu1TZZ9ZhrXQ Content-language: en-us X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTURzHObt3917N2XWW/lhU60aQhcutqdfSHhRxKyOjQCjKrnpwK7fJ 7owsCns/7SmY03wUlU0tGrYsepglPaiozLCV0sMKs0zLjAiq666B/33O+X2/v9c5DKG9QOkY q92FnXYxm6OCSd+tqPDoqWE1qTHlF1R8580Smv9y4qyaP1mXxJ/d81rNN18ppfj2mr9q/vSP rzTfdr+J4gtK9XzhgTY0K1i47G6jBa9nDyV4vx2hhQN1HiRUVf+khe/eMSnUcpxowWImduqx PcORabVnJXELl6bNSYuNizFGGxP4eE5vF204iZubnBI9z5otN8bp14nZufJViihJ3JQZiU5H rgvrLQ7JlcStMBpNBmNMvMFkMhnMsSunmWJlyWpsuVf0lMzp49Y31/fS+ejcqL0oiAHWDOXe X5TCEfC4/bzMwYyWPYWgt/gXoRy+I/A1PEf/HaXfrpFKoFoOPPUEAhQbBS3+SvUAj2CnQGVr bSAtwR5XgWfX2AEOYpfAx1d3iQEOZ9Nha31ZQE+yE6ClvzOQR8MmQPnublLhMLhX3EEqeaJg x6XftMKT4XRlF6E0pIf6h12yl5HrLoet2yIVSSR0Nt2mB/oE9hEND/oLAhpgR4O3YdA6F7YU /aUVDodPd+oGWQfbenvUincfgvwnd1XKoRBB36U3g/uaCQ29rYRSLRROnn9NKQU0sHunVkEB PB2bFPVs6Lh6lFb21q2Cg80VxCGkdw8Z0z1kTPeQMd1D5qlApAdF4BzJloWlqTm8QRJtUq49 y5DhsHlR4LtOiqhHZVULGhHLIC5EI1irU7VqcZ2UZ2tEwBDcCM18tiZVq8kU8zZgpyPNmZuN pUYUKz/DYUI3MsMhf367K81ojjOaTXGmmHjelMBFavYHbU7VslmiC6/FOAc7//tUTJAuH22/ +Ka2/9j9o4sjfG/DQux5z0Kmt0ZVrLeVHBvzblfb0mLv9Gpho+oZ01SaEZ2y5kHfTd6ffh2L Z7r9y2p1yV3v3493C2R41biCwlbv5jVhvpe/fd1l/kVr00teWFZNHOcWJrdvmldyu/NDZai/ 6obwx9zyMvTTsMSe4Z+tPc7kllCOlCyicRLhlMR/U0MvW8QDAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLIsWRmVeSWpSXmKPExsWSnXP7iq6R4Jpwg3kXjSxeHpzNbvF20UpW i8VbbC1Wdj5gtbi8aw6bxb01/1ktln19z25x99RRNoveOQoWU/ruMjpweeycdZfdY9OqTjaP TZ8msXv0bVnF6LFi9Xd2j8+b5ALYotxsMlITU1KLFFLzkvNTMvPSbZVCQ9x0LZQU8hJzU22V InR9Q4KUFMoSc0qBPCMDNODgHOAerKRvl+CWcXL6JZaCL0oVl3d8ZG9gXCfdxcjJISFgIjHn 014WCFtM4sK99WxdjFwcQgIrGSV+tJwFS7AJaEpcvbWQFcQWEdCXWHhjLVgRs8BSJolvv+4x QnQ8Y5JYfrifCaSKUyBQ4vmdE8wgtrBAgsSFyVfBJrEIqEpc/faSEcTmFbCUmN/xjgXCFpQ4 OfMJmM0soC3R+7CVEcZetvA1M8R5ChI7zr4GinMAXREl0dQsDlEiLvHy6BH2CYyCs5BMmoVk 0iwkk2YhaVnAyLKKUSy1oDg3Pbe4wMBQrzgxt7g0L10vOT93EyMwarcdVhLbwdi2wusQowAH oxIPL8OB1eFCrIllxZW5hxglOJiVRHg9BdaEC/GmJFZWpRblxxeV5qQWH2I0Bfp0IrOUaHI+ MKHklcQbmphaWFiYWBobG1uYKInzCt6tCxcSSE8sSc1OTS1ILYLpY+LglGpg7NHYU+4kqL80 70i+J4s2Z8VB0/8HRbInnWJX/cw804Fj1W52jqx93cx/ukVn5otflP3ZON3I/E6Hp8JH2SgJ 2TlRqXoCF6oz9zn+zfyfuprbw/Ibe6FW+N2URTEn374N/xl3V1TuSfrJmTbbr2yRebm6Z1Xf vWepGwzNbN+FeO+X37Dq5YSNSizFGYmGWsxFxYkAuZyLdPACAAA= X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20160811054626epcas3p376f8ed4096c5a63d27a6f047c238f97a X-Msg-Generator: CA X-Sender-IP: 182.195.34.22 X-Local-Sender: =?UTF-8?B?UElOVFUgQUdBUldBTBtTUkktQmFuZ2Fsb3JlLUtlcm5lbCAm?= =?UTF-8?B?IEJTUBvsgrzshLHsoITsnpAbUHJpbmNpcGFsIEVuZ2luZWVy?= X-Global-Sender: =?UTF-8?B?UElOVFUgS1VNQVIbU1JJLUJhbmdhbG9yZS1LZXJuZWwgJiBC?= =?UTF-8?B?U1AbU2Ftc3VuZyBFbGVjdHJvbmljcxtQcmluY2lwYWwgRW5naW5lZXI=?= X-Sender-Code: =?UTF-8?B?QzEwG1NXQUhRG0MxMElEMDFJRDAxMDYxNg==?= CMS-TYPE: 103P DLP-Filter: Pass X-CFilter-Loop: Reflected X-HopCount: 7 X-CMS-RootMailID: 20160805045709epcas3p1dc6f12f2fa3031112c4da5379e33b5e9 X-RootMTR: 20160805045709epcas3p1dc6f12f2fa3031112c4da5379e33b5e9 References: <01a001d1eed5$c50726c0$4f157440$@samsung.com> <20160805082015.GA28235@bbox> <01c101d1ef28$50706ad0$f1514070$@samsung.com> <20160805205018.GE7999@amd> <006e01d1f30a$bfc7f430$3f57dc90$@samsung.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, > -----Original Message----- > From: vinayak menon [mailto:vinayakm.list@gmail.com] > Sent: Thursday, August 11, 2016 10:23 AM > To: PINTU KUMAR > Cc: Pavel Machek; Konstantin Khlebnikov; Minchan Kim; linux- > kernel@vger.kernel.org; linux-mm@kvack.org; jaejoon.seo@samsung.com; > jy0.jeon@samsung.com; vishnu.ps@samsung.com; chulspro.kim@samsung.com > Subject: Re: [linux-mm] Drastic increase in application memory usage with Kernel > version upgrade > > On Wed, Aug 10, 2016 at 6:56 PM, PINTU KUMAR wrote: > > Hi, > > > >> -----Original Message----- > >> From: Pavel Machek [mailto:pavel@ucw.cz] > >> Sent: Saturday, August 06, 2016 2:20 AM > >> To: PINTU KUMAR > >> Cc: 'Minchan Kim'; linux-kernel@vger.kernel.org; linux-mm@kvack.org; > >> jaejoon.seo@samsung.com; jy0.jeon@samsung.com; > vishnu.ps@samsung.com > >> Subject: Re: [linux-mm] Drastic increase in application memory usage > >> with > > Kernel > >> version upgrade > >> > >> On Fri 2016-08-05 20:17:36, PINTU KUMAR wrote: > >> > Hi, > >> > >> > > On Fri, Aug 05, 2016 at 10:26:37AM +0530, PINTU KUMAR wrote: > >> > > > Hi All, > >> > > > > >> > > > For one of our ARM embedded product, we recently updated the > >> > > > Kernel version from 3.4 to 3.18 and we noticed that the same > >> > > > application memory usage (PSS value) gone up by ~10% and for > >> > > > some cases it even crossed ~50%. There is no change in platform > >> > > > part. All platform component was built with ARM 32-bit toolchain. > >> > > > However, the Kernel is changed from 32-bit to 64-bit. > >> > > > > >> > > > Is upgrading Kernel version and moving from 32-bit to 64-bit is > >> > > > such a risk? > >> > > > After the upgrade, what can we do further to reduce the > >> > > > application memory usage ? > >> > > > Is there any other factor that will help us to improve without > >> > > > major modifications in platform ? > >> > > > > >> > > > As a proof, we did a small experiment on our Ubuntu-32 bit machine. > >> > > > We upgraded Ubuntu Kernel version from 3.13 to 4.01 and we > >> > > > observed the following: > >> > > > --------------------------------------------------------------- > >> > > > --- > >> > > > |UBUNTU-32 bit |Kernel 3.13 |Kernel 4.03 |DIFF | > >> > > > |CALCULATOR PSS |6057 KB |6466 KB |409 KB | > >> > > > --------------------------------------------------------------- > >> > > > --- So, just by upgrading the Kernel version: PSS value for > >> > > > calculator is increased by 409KB. > >> > > > > >> > > > If anybody knows any in-sight about it please point out more > >> > > > details about the root cause. > >> > > > >> > > One of culprit is [8c6e50b0290c, mm: introduce vm_ops->map_pages()]. > >> > Ok. Thank you for your reply. > >> > So, if I revert this patch, will the memory usage be decreased for > >> > the processes with Kernel 3.18 ? > >> > >> I guess you should try it... > >> > > Thanks for the reply and confirmation. > > Our exact kernel version is: 3.18.14 > > And, we already have this patch: > > /* > > mm: do not call do_fault_around for non-linear fault Ingo Korb > > reported that "repeated mapping of the same file on tmpfs using > > remap_file_pages sometimes triggers a BUG at mm/filemap.c:202 when the > > process exits". > > He bisected the bug to d7c1755179b8 ("mm: implement ->map_pages for > > shmem/tmpfs"), although the bug was actually added by commit > > 8c6e50b0290c ("mm: introduce vm_ops->map_pages()"). > > */ > > > > So, I guess, reverting this patch (8c6e50b0290c), is not required ? > > But, still we have memory usage issue. > > > I had observed the PSS increase with 3.18, and that was because of the > faultaround patch which MInchan mentioned. > Without reverting the patch you can just try reducing fault_around_bytes > (mm/memory.c) to PAGE_SIZE. That should bring down the PSS. > Thanks for your reply. I tried changing fault_around_bytes value from 65536 to 4096. But, still there is no change in PSS. Please let me know if anything is missing. --- a/mm/memory.c +++ b/mm/memory.c @@ -2776,7 +2776,8 @@ void do_set_pte(struct vm_area_struct *vma, unsigned long address, } static unsigned long fault_around_bytes __read_mostly = - rounddown_pow_of_two(65536); + rounddown_pow_of_two(PAGE_SIZE); > Thanks, > Vinayak