[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <548B6BB8-FD6F-4F8D-B67F-2809305C617D@gmail.com>
Date: Fri, 23 Mar 2018 20:49:03 +0300
From: Ilya Smith <blackzert@...il.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: rth@...ddle.net, ink@...assic.park.msu.ru, mattst88@...il.com,
vgupta@...opsys.com, linux@...linux.org.uk, tony.luck@...el.com,
fenghua.yu@...el.com, jhogan@...nel.org, ralf@...ux-mips.org,
jejb@...isc-linux.org, deller@....de, benh@...nel.crashing.org,
paulus@...ba.org, mpe@...erman.id.au, schwidefsky@...ibm.com,
heiko.carstens@...ibm.com, ysato@...rs.sourceforge.jp,
dalias@...c.org, davem@...emloft.net, tglx@...utronix.de,
mingo@...hat.com, hpa@...or.com, x86@...nel.org,
nyc@...omorphy.com, viro@...iv.linux.org.uk, arnd@...db.de,
gregkh@...uxfoundation.org, deepa.kernel@...il.com,
mhocko@...e.com, hughd@...gle.com, kstewart@...uxfoundation.org,
pombredanne@...b.com, steve.capper@....com, punit.agrawal@....com,
paul.burton@...s.com, aneesh.kumar@...ux.vnet.ibm.com,
npiggin@...il.com, keescook@...omium.org, bhsharma@...hat.com,
riel@...hat.com, nitin.m.gupta@...cle.com,
kirill.shutemov@...ux.intel.com, dan.j.williams@...el.com,
jack@...e.cz, ross.zwisler@...ux.intel.com, jglisse@...hat.com,
willy@...radead.org, aarcange@...hat.com, oleg@...hat.com,
linux-alpha@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-snps-arc@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-ia64@...r.kernel.org,
linux-metag@...r.kernel.org, linux-mips@...ux-mips.org,
linux-parisc@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
linux-s390@...r.kernel.org, linux-sh@...r.kernel.org,
sparclinux@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [RFC PATCH v2 2/2] Architecture defined limit on memory region
random shift.
> On 22 Mar 2018, at 23:54, Andrew Morton <akpm@...ux-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.
Powered by blists - more mailing lists