lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 5 Aug 2016 17:20:15 +0900 From: Minchan Kim <minchan@...nel.org> To: PINTU KUMAR <pintu.k@...sung.com> CC: <linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>, <jaejoon.seo@...sung.com>, <jy0.jeon@...sung.com>, <vishnu.ps@...sung.com> Subject: Re: [linux-mm] Drastic increase in application memory usage with Kernel version upgrade 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()].
Powered by blists - more mailing lists