linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: PINTU KUMAR <pintu.k@samsung.com>
To: 'Pavel Machek' <pavel@ucw.cz>, koct9i@gmail.com
Cc: 'Minchan Kim' <minchan@kernel.org>,
	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
Date: Wed, 10 Aug 2016 18:56:02 +0530	[thread overview]
Message-ID: <006e01d1f30a$bfc7f430$3f57dc90$@samsung.com> (raw)
In-Reply-To: <20160805205018.GE7999@amd>

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.

> You may want to try the same kernel version, once in 32-bit and once in 64-bit
> version. And you may consider moving to recent kernel.
> 
Sorry, but moving to higher kernel version is not possible as of now. 
As it involves other BSP changes.
We can only upgrades the relevant patches.
However, as I said earlier, we even found the difference on Ubuntu 32-bit 
after moving from Kernel-3.13 to 4.0.
So, I guess, this problem exists even in higher kernel version too.

> Yes, 64-bit kernel will increase memory usage _of kernel_, but...
> 
Ok, But ?
Will it be major culprit ? Or higher kernel version is major culprit ?

> 
> 	Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2016-08-10 13:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20160805045709epcas3p1dc6f12f2fa3031112c4da5379e33b5e9@epcas3p1.samsung.com>
2016-08-05  4:56 ` [linux-mm] Drastic increase in application memory usage with Kernel version upgrade PINTU KUMAR
2016-08-05  8:20   ` Minchan Kim
2016-08-05 14:47     ` PINTU KUMAR
2016-08-05 20:50       ` Pavel Machek
2016-08-10 13:26         ` PINTU KUMAR [this message]
2016-08-11  4:53           ` vinayak menon
2016-08-11  5:45             ` PINTU KUMAR

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='006e01d1f30a$bfc7f430$3f57dc90$@samsung.com' \
    --to=pintu.k@samsung.com \
    --cc=chulspro.kim@samsung.com \
    --cc=jaejoon.seo@samsung.com \
    --cc=jy0.jeon@samsung.com \
    --cc=koct9i@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=pavel@ucw.cz \
    --cc=vishnu.ps@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).