From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ilya Smith Subject: Re: [RFC PATCH v2 2/2] Architecture defined limit on memory region random shift. Date: Fri, 23 Mar 2018 20:48:00 +0300 Message-ID: <5D55B1FC-1962-4941-BF56-1F83554FC64C@gmail.com> References: <1521736598-12812-1-git-send-email-blackzert@gmail.com> <1521736598-12812-3-git-send-email-blackzert@gmail.com> <20180322135448.046ada120ecd1ab3dd8f94aa@linux-foundation.org> Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B9437F76-CEDD-4524-828D-E63FF8E38C7F"; protocol="application/pgp-signature"; micalg=pgp-sha256 Cc: kstewart@linuxfoundation.org, linux-mips@linux-mips.org, dalias@libc.org, Jan Kara , linux-sh@vger.kernel.org, bhsharma@redhat.com, heiko.carstens@de.ibm.com, jejb@parisc-linux.org, Linux-MM , Michal Hocko , paulus@samba.org, deepa.kernel@gmail.com, hpa@zytor.com, sparclinux@vger.kernel.org, linux-ia64@vger.kernel.org, Dan Williams , Andrea Arcangeli , linux-s390@vger.kernel.org, ysato@users.sourceforge.jp, Helge Deller , x86@kernel.org, Hugh Dickins , linux@armlinux.org.uk, Matthew Wilcox , nitin.m.gupta@oracle.com, linux-alpha@vger.kernel.org, mingo@redhat.com, mattst88@gmail.com, linux-snps-arc@lists.infradead.org, fenghua.yu@intel.com, riel@redhat.com, punit.agrawal@arm.com, Kees Cook , arnd@arn To: Andrew Morton Return-path: In-Reply-To: <20180322135448.046ada120ecd1ab3dd8f94aa@linux-foundation.org> List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org --Apple-Mail=_B9437F76-CEDD-4524-828D-E63FF8E38C7F Content-Type: multipart/alternative; boundary="Apple-Mail=_302D41D8-B8D8-4A57-A90C-AE132EC44462" --Apple-Mail=_302D41D8-B8D8-4A57-A90C-AE132EC44462 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 22 Mar 2018, at 23:54, Andrew Morton = wrote: >=20 >=20 > Please add changelogs. An explanation of what a "limit on memory > region random shift" is would be nice ;) Why does it exist, why are we > doing this, etc. Surely there's something to be said - at present = this > is just a lump of random code? >=20 Sorry, my bad. The main idea of this limit is to decrease possible = memory fragmentation. This is not so big problem on 64bit process, but really = big for 32 bit processes since may cause failure memory allocation. To control = memory fragmentation and protect 32 bit systems (or architectures) this limit = was introduce by this patch. It could be also moved to CONFIG_ as well. --Apple-Mail=_302D41D8-B8D8-4A57-A90C-AE132EC44462 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On = 22 Mar 2018, at 23:54, Andrew Morton <akpm@linux-foundation.org> wrote:

Please add changelogs. An explanation of what a "limit = on memory
region random shift" is would be nice ;) Why = does it exist, why are we
doing this, etc. Surely = there's something to be said - at present this
is just a = lump of random code?

Sorry, = my bad. The main idea of this limit is to decrease possible = memory

fragmentation. This is not so big problem on 64bit process, = but really big for

32 bit = processes since may cause failure memory allocation. To control = memory

fragmentation and protect 32 bit systems (or architectures) = this limit was

introduce= by this patch. It could be also moved to CONFIG_ as = well.

= --Apple-Mail=_302D41D8-B8D8-4A57-A90C-AE132EC44462-- --Apple-Mail=_B9437F76-CEDD-4524-828D-E63FF8E38C7F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEju7OBNw5xIMUzNy9WTzOquRR3DcFAlq1PdAACgkQWTzOquRR 3Ddp9BAAmPUV7u9gSEqLavwAr5Hu+ZmmSJS7i95PzubMqxmQosuS52Z4/bUbBubG rpcg0eym8hpSfWnUs+SyF4od/d1elKMcF0Xy16b48F7xeGARHOBsxp2WXVdLDxVN veTQKZ5skp9MHHAPJZbrwJqslKksWdisVWxx14XXWt3o+LqeG5/O7XORxC4zqAEv wa4BvuDBg86I6/J+5+8aMVeucisrk/DKxG1sWWXWsRkQYDK8+V1pO0RUuxDSHu9K 5YDyvXzdcXy1NML+LAmtPO9xDK+6jI0YVFY6Ifp1wbVYI5KwDLWiAchEYPnHTmcI 719Wfy9aLBVnG8EyOCR1z86LegVJ0AKUidWovh+fhOZ3kO8rbmr9yv7FV0WXzf98 1HUZBQWwW3UuDOb3t/83TMeNHtq/kb0NXD+bjb4NFJUnYS15lYDe9YPhO5MKCudT X0prbA/oipnJQojAzlITFNUt2N7N+53OxDEdXHzrQDuT0g/wdheM5q27VvQ+EdE5 72YRH72brGkh+b/QhreLK3OjiGa6AWdWpqr+5ERn4TVt1IRBSfRAq5zHAxgDk97S 81cRvJgLR0n2NEXHNrvyjIZebfLuc5CmPiTs4tLHpDYnrrUZtsuQyXk53hSiUmGs KzBn/WKQGxswsjPNqzFNDNIaf67VXSlf4QQmegh2Fl8GGC8v8pg= =6qWL -----END PGP SIGNATURE----- --Apple-Mail=_B9437F76-CEDD-4524-828D-E63FF8E38C7F-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: ARC-Seal: i=1; a=rsa-sha256; t=1521827284; cv=none; d=google.com; s=arc-20160816; b=SCto+aqZKPHswJv+65Amz06XIOK62+r02XD55vaLrCbKL+vWvPUyfQOVnPlxFjzmr2 sbgatSvInYbdOVtTFMGRJcQvkN/19Zfd29KBl2xJP9LPtl392zwaojrRjc/zOn1VlFkq 2wr7dB7yew5zVBxkAo7lq6ewmzy/6du4L2GcbpGEjA5mwkcFZgwehtVQySgxhyrYlNsK nNQAtTFz9P+TDGlZ6tPTgltdo0iHiwozAzpO0DrJULaLCEAq06JuB3tByJmciGuTotV0 C2qE24sPCRbPtzb3b1j5b5NSf/AOujx5WJO8v72g2qGHwWo97ImcSB7xvpl73GrG9wqK s9Xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:dkim-signature:arc-authentication-results; bh=uetvGUCojhaZF1cGzHJVZuEIcoQzSG0BT2smcOYhyeQ=; b=vAU/uX0JzBIdRF2h6FDqVgVKpLVY0iUdTLYU42iRzkc+5LuFC5KJ4nANkHfUTfSnC5 1CYQj44QJJjxfrlkJl1WdEz4tIu2lqBWQ/qIkgCl/SQn9RyenSPUurlWV9t/S9VmM+ng W8LJZfBqrzDJWGYGATGvbqxMROg33yf2HvLoCJcY05xRBLIi7vCthENIrnTtSIVDp+gx bCizeS0ICVs2IADVqPhVZTPSvBQZ9/cPhauzYD1hmn7PVZLmh9bsK4h9K1xtLQX6ZbBM j3UPlWY35TblIM27wXXslH17hS8sGfroS+WwYFwg0jeibnir57b36m8Hhy+/4AO4Stiz u/nw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=kPomwbVs; spf=pass (google.com: domain of blackzert@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=blackzert@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=kPomwbVs; spf=pass (google.com: domain of blackzert@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=blackzert@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com X-Google-Smtp-Source: AG47ELvprX88V7gLuVZjyauKh2sGf/w8hTcCfNXTQOawcQ8luvrMZKgmu799Ex/UO4EerUiQDmWsxQ== From: Ilya Smith Message-Id: <5D55B1FC-1962-4941-BF56-1F83554FC64C@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_B9437F76-CEDD-4524-828D-E63FF8E38C7F"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: [RFC PATCH v2 2/2] Architecture defined limit on memory region random shift. Date: Fri, 23 Mar 2018 20:48:00 +0300 In-Reply-To: <20180322135448.046ada120ecd1ab3dd8f94aa@linux-foundation.org> Cc: rth@twiddle.net, ink@jurassic.park.msu.ru, mattst88@gmail.com, vgupta@synopsys.com, linux@armlinux.org.uk, tony.luck@intel.com, fenghua.yu@intel.com, ralf@linux-mips.org, jejb@parisc-linux.org, Helge Deller , benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, ysato@users.sourceforge.jp, dalias@libc.org, davem@davemloft.net, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, nyc@holomorphy.com, viro@zeniv.linux.org.uk, arnd@arndb.de, gregkh@linuxfoundation.org, deepa.kernel@gmail.com, Michal Hocko , Hugh Dickins , kstewart@linuxfoundation.org, pombredanne@nexb.com, steve.capper@arm.com, punit.agrawal@arm.com, aneesh.kumar@linux.vnet.ibm.com, npiggin@gmail.com, Kees Cook , bhsharma@redhat.com, riel@redhat.com, nitin.m.gupta@oracle.com, "Kirill A. Shutemov" , Dan Williams , Jan Kara , ross.zwisler@linux.intel.com, Jerome Glisse , Matthew Wilcox , Andrea Arcangeli , Oleg Nesterov , linux-alpha@vger.kernel.org, LKML , linux-snps-arc@lists.infradead.org, linux-ia64@vger.kernel.org, linux-metag@vger.kernel.org, linux-mips@linux-mips.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, Linux-MM To: Andrew Morton References: <1521736598-12812-1-git-send-email-blackzert@gmail.com> <1521736598-12812-3-git-send-email-blackzert@gmail.com> <20180322135448.046ada120ecd1ab3dd8f94aa@linux-foundation.org> X-Mailer: Apple Mail (2.3445.5.20) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1595656493467338178?= X-GMAIL-MSGID: =?utf-8?q?1595751566509464944?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: --Apple-Mail=_B9437F76-CEDD-4524-828D-E63FF8E38C7F Content-Type: multipart/alternative; boundary="Apple-Mail=_302D41D8-B8D8-4A57-A90C-AE132EC44462" --Apple-Mail=_302D41D8-B8D8-4A57-A90C-AE132EC44462 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 22 Mar 2018, at 23:54, Andrew Morton = wrote: >=20 >=20 > Please add changelogs. An explanation of what a "limit on memory > region random shift" is would be nice ;) Why does it exist, why are we > doing this, etc. Surely there's something to be said - at present = this > is just a lump of random code? >=20 Sorry, my bad. The main idea of this limit is to decrease possible = memory fragmentation. This is not so big problem on 64bit process, but really = big for 32 bit processes since may cause failure memory allocation. To control = memory fragmentation and protect 32 bit systems (or architectures) this limit = was introduce by this patch. It could be also moved to CONFIG_ as well. --Apple-Mail=_302D41D8-B8D8-4A57-A90C-AE132EC44462 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On = 22 Mar 2018, at 23:54, Andrew Morton <akpm@linux-foundation.org> wrote:

Please add changelogs. An explanation of what a "limit = on memory
region random shift" is would be nice ;) Why = does it exist, why are we
doing this, etc. Surely = there's something to be said - at present this
is just a = lump of random code?

Sorry, = my bad. The main idea of this limit is to decrease possible = memory

fragmentation. This is not so big problem on 64bit process, = but really big for

32 bit = processes since may cause failure memory allocation. To control = memory

fragmentation and protect 32 bit systems (or architectures) = this limit was

introduce= by this patch. It could be also moved to CONFIG_ as = well.