From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
To: Mike Rapoport <rppt@kernel.org>, Guenter Roeck <linux@roeck-us.net>
Cc: Rich Felker <dalias@libc.org>,
"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
"x86@kernel.org" <x86@kernel.org>,
Michal Hocko <mhocko@kernel.org>,
"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
Max Filippov <jcmvbkbc@gmail.com>, Guo Ren <guoren@kernel.org>,
Ley Foon Tan <ley.foon.tan@intel.com>,
"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
"linux-riscv@lists.infradead.org"
<linux-riscv@lists.infradead.org>,
Greg Ungerer <gerg@linux-m68k.org>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
linux-c6x-dev@linux-c
Subject: Re: [PATCH v2 17/20] mm: free_area_init: allow defining max_zone_pfn in descending order
Date: Tue, 05 May 2020 06:23:37 +0000 [thread overview]
Message-ID: <a0b20e15-fddb-aa9c-fd67-f1c8e735b4a4@synopsys.com> (raw)
In-Reply-To: <20200504153901.GM14260@kernel.org>
SGkgTWlrZSwNCg0KT24gNS80LzIwIDg6MzkgQU0sIE1pa2UgUmFwb3BvcnQgd3JvdGU6DQo+IE9u
IFN1biwgTWF5IDAzLCAyMDIwIGF0IDExOjQzOjAwQU0gLTA3MDAsIEd1ZW50ZXIgUm9lY2sgd3Jv
dGU6DQo+PiBPbiBTdW4sIE1heSAwMywgMjAyMCBhdCAxMDo0MTozOEFNIC0wNzAwLCBHdWVudGVy
IFJvZWNrIHdyb3RlOg0KPj4+IEhpLA0KPj4+DQo+Pj4gT24gV2VkLCBBcHIgMjksIDIwMjAgYXQg
MDM6MTE6MjNQTSArMDMwMCwgTWlrZSBSYXBvcG9ydCB3cm90ZToNCj4+Pj4gRnJvbTogTWlrZSBS
YXBvcG9ydCA8cnBwdEBsaW51eC5pYm0uY29tPg0KPj4+Pg0KPj4+PiBTb21lIGFyY2hpdGVjdHVy
ZXMgKGUuZy4gQVJDKSBoYXZlIHRoZSBaT05FX0hJR0hNRU0gem9uZSBiZWxvdyB0aGUNCj4+Pj4g
Wk9ORV9OT1JNQUwuIEFsbG93aW5nIGZyZWVfYXJlYV9pbml0KCkgcGFyc2UgbWF4X3pvbmVfcGZu
IGFycmF5IGV2ZW4gaXQgaXMNCj4+Pj4gc29ydGVkIGluIGRlc2NlbmRpbmcgb3JkZXIgYWxsb3dz
IHVzaW5nIGZyZWVfYXJlYV9pbml0KCkgb24gc3VjaA0KPj4+PiBhcmNoaXRlY3R1cmVzLg0KPj4+
Pg0KPj4+PiBBZGQgdG9wIC0+IGRvd24gdHJhdmVyc2FsIG9mIG1heF96b25lX3BmbiBhcnJheSBp
biBmcmVlX2FyZWFfaW5pdCgpIGFuZCB1c2UNCj4+Pj4gdGhlIGxhdHRlciBpbiBBUkMgbm9kZS96
b25lIGluaXRpYWxpemF0aW9uLg0KPj4+Pg0KPj4+PiBTaWduZWQtb2ZmLWJ5OiBNaWtlIFJhcG9w
b3J0IDxycHB0QGxpbnV4LmlibS5jb20+DQo+Pj4NCj4+PiBUaGlzIHBhdGNoIGNhdXNlcyBteSBt
aWNyb2JsYXplZWwgcWVtdSBib290IHRlc3QgaW4gbGludXgtbmV4dCB0byBmYWlsLg0KPj4+IFJl
dmVydGluZyBpdCBmaXhlcyB0aGUgcHJvYmxlbS4NCj4+Pg0KPj4gVGhlIHNhbWUgcHJvYmxlbSBp
cyBzZWVuIHdpdGggczM5MCBlbXVsYXRpb25zLg0KPiANCj4gWWVhaCwgdGhpcyBwYXRjaCBicmVh
a3Mgc29tZSBvdGhlcnMgYXMgd2VsbCA6KA0KPiANCj4gTXkgYXNzdW1wdGlvbiB0aGF0IG1heF96
b25lX3BmbiBkZWZpbmVzIGFyY2hpdGVjdHVyYWwgbGltaXQgZm9yIG1heGltYWwNCj4gUEZOIHRo
YXQgY2FuIGJlbG9uZyB0byBhIHpvbmUgd2FzIG92ZXItb3B0aW1pc3RpYy4gU2V2ZXJhbCBhcmNo
ZXMNCj4gYWN0dWFsbHkgZG8gdGhhdCwgYnV0IG90aGVycyBkbw0KPiANCj4gCW1heF96b25lX3Bm
bltaT05FX0RNQV0gPSBNQVhfRE1BX1BGTjsNCj4gCW1heF96b25lX3BmbltaT05FX05PUk1BTF0g
PSBtYXhfcGZuOw0KPiANCj4gd2hlcmUgTUFYX0RNQV9QRk4gaXMgYnVpbGQtdGltZSBjb25zdHJh
aW4gYW5kIG1heF9wZm4gaXMgcnVuIHRpbWUgbGltaXQNCj4gZm9yIHRoZSBjdXJyZW50IHN5c3Rl
bS4NCj4gDQo+IFNvLCB3aGVuIG1heF9wZm4gaXMgbG93ZXIgdGhhbiBNQVhfRE1BX1BGTiwgdGhl
IGZyZWVfaW5pdF9hcmVhKCkgd2lsbA0KPiBjb25zaWRlciBtYXhfem9uZV9wZm4gYXMgZGVzY2Vu
ZGluZyBhbmQgd2lsbCB3cm9uZ2x5IGNhbGN1bGF0ZSB6b25lDQo+IGV4dGVudHMuDQo+IA0KPiBU
aGF0IHNhaWQsIGluc3RlYWQgb2YgdHJ5aW5nIHRvIGNyZWF0ZSBhIGdlbmVyaWMgd2F5IHRvIHNw
ZWNpYWwgY2FzZQ0KPiBBUkMsIEkgc3VnZ2VzdCB0byBzaW1wbHkgdXNlIHRoZSBiZWxvdyBwYXRj
aCBpbnN0ZWFkLg0KDQpFdmVuIGZvciBBUkMgaXQgd2lsbCBiZSBhIGJpdCBtb3JlIGNvbXBsaWNh
dGVkLiBIaWdobWVtIG9uIEFSQyBjYW4gYmUgc2V0dXAgaW4gMg0Kd2F5cyBzdWNoIHRoYXQgaXQg
aXMgZGVzY2VuZGluZyBpbiBvbmUgY2FzZSwgYW5kIGFzY2VuZGluZyBpbiBvdGhlciAody5yLnQN
CiJub3JtYWwiIG1lbSkgOi0oDQoNCkZpcnN0IHNvbWUgYmFzaWMgaW5mbyBhYm91dCBhbiBBUkMg
TU1VIGJhc2VkIHN5c3RlbQ0KDQpBUkMgbG9naWNhbCBhZGRyZXNzIHNwYWNlICh2YXJpb3VzIGFk
ZHJlc3NlcyBlbWJlZGRlZCBpbiBiaW5hcmllcykNCiAtIHRyYW5zbGF0ZWQgKDAgdG8gMHg2RkZG
X0ZGRkYpICAtIGZvciB1c2Vyc3BhY2UNCiAtIHVudHJhbnNsYXRlZCAoMHg4MDAwXzAwMDAgdG8g
MHhGRkZGX0ZGRkYpIC0ga2VybmVsDQoNCkFSQyBQaHlzaWNhbCBhZGRyZXNzIHNwYWNlIGlzIHR5
cGljYWxseSBmcm9tIDB4ODAwMF8wMDAwIHRvIDB4RjAwMF8wMDAwLg0KQWJvdmUgdHJhbnNsYXRl
ZCBzcGFjZSBtYXBzIGhlcmUgdmlhIE1NVS4gVW50cmFuc2xhdGVkIGlzIGltcGxpY2l0bHkgbWFw
cGVkIChubw0KTU1VIGludm9sdmVkKS4NCg0KVGhlIHBoeXNpY2FsIGFkZHJlc3MgaW4gdHVybiBt
YXBzIHRvIGEgQnVzIGFkZHJlc3MgLyBtZW1vcnkgKGRvbmUgYXQgdGhlDQppbnRlci1jb25uZWN0
L05vQykuIFR5cGljYWxseSBQaHlzaWNhbCAweDgwMDBfMDAwMCBtYXAgdG8gRERSIDANCg0KTm93
LA0KLSBISUdITUVNIHcvbyBQQUU0MCBhZGRzIFBoeXNpY2FsIGFkZHJlc3Mgc3BhY2UgMCB0byAw
eDdGRkZfRkZGRi4NCi0gSElHSE1FTSB3aXRoIFBBRTQwIHVzZXMgcGh5c2ljYWwgYWRkcmVzcyBz
cGFjZSBmcm9tIDB4MV8wMDAwXzAwMDAgdXB3YXJkcy4NCg0KQnV0IHRoZW4geW91IGNvdWxkIGFs
c28gaGF2ZSBhIHN5c3RlbSB3aGljaCBoYXMgYm90aCBvZiBhYm92ZSBzbyB0aGUgYmltb2RhbCB1
cC9kbg0Kd29uJ3Qgd29yay4NCg0KV2hpbGUgSSBhcHByZWNpYXRlIHRoZSBlZmZvcnQgdG8gcmVk
dWNlIGNvbXBsZXhpdHksIGl0IHNlZW1zIHRoZSBjdXJyZW50IHdheSBvZg0Kc2V0dGluZyB0aGlu
Z3MgdXAgYWxsb3dzIGZvciBtb3JlIGZsZXhpYmlsaXR5IGluIHNwZWNpZnlpbmcgdGhlIHN5c3Rl
bSBtZW1vcnkgbWFwLg0KDQpQUzogSSBoYXZlbid0IGxvb2tlZCBhdCB5b3VyIHNlcmllcyB0b28g
Y2FyZWZ1bGx5LCB0aGUgbWVudGlvbiBvZiBBUkMgY2F1Z2h0IG15DQphdHRlbnRpb24gOi0pIEkg
Z3Vlc3MgSSBuZWVkIHRvIHJlYWQgaXQgbW9yZSBjYXJlZnVsbHkgdG8gdW5kZXJzdGFuZC4NCg0K
DQo+IA0KPiBkaWZmIC0tZ2l0IGEvYXJjaC9hcmMvbW0vaW5pdC5jIGIvYXJjaC9hcmMvbW0vaW5p
dC5jDQo+IGluZGV4IDQxZWI5YmUxNjUzYy4uMzg2OTU5YmFjM2QyIDEwMDY0NA0KPiAtLS0gYS9h
cmNoL2FyYy9tbS9pbml0LmMNCj4gKysrIGIvYXJjaC9hcmMvbW0vaW5pdC5jDQo+IEBAIC03Nyw2
ICs3NywxMSBAQCB2b2lkIF9faW5pdCBlYXJseV9pbml0X2R0X2FkZF9tZW1vcnlfYXJjaCh1NjQg
YmFzZSwgdTY0IHNpemUpDQo+ICAJCWJhc2UsIFRPX01CKHNpemUpLCAhaW5fdXNlID8gIk5vdCB1
c2VkIjoiIik7DQo+ICB9DQo+ICANCj4gK2Jvb2wgYXJjaF9oYXNfZGVzY2VuZGluZ19tYXhfem9u
ZV9wZm5zKHZvaWQpDQo+ICt7DQo+ICsJcmV0dXJuIHRydWU7DQo+ICt9DQo+ICsNCj4gIC8qDQo+
ICAgKiBGaXJzdCBtZW1vcnkgc2V0dXAgcm91dGluZSBjYWxsZWQgZnJvbSBzZXR1cF9hcmNoKCkN
Cj4gICAqIDEuIHNldHVwIHN3YXBwZXIncyBtbSBAaW5pdF9tbQ0KPiBkaWZmIC0tZ2l0IGEvbW0v
cGFnZV9hbGxvYy5jIGIvbW0vcGFnZV9hbGxvYy5jDQo+IGluZGV4IGI5OTBlOTczNDQ3NC4uMTE0
ZjBlMDI3MTQ0IDEwMDY0NA0KPiAtLS0gYS9tbS9wYWdlX2FsbG9jLmMNCj4gKysrIGIvbW0vcGFn
ZV9hbGxvYy5jDQo+IEBAIC03MzA3LDYgKzczMDcsMTUgQEAgc3RhdGljIHZvaWQgY2hlY2tfZm9y
X21lbW9yeShwZ19kYXRhX3QgKnBnZGF0LCBpbnQgbmlkKQ0KPiAgCX0NCj4gIH0NCj4gIA0KPiAr
LyoNCj4gKyAqIFNvbWUgYXJjaGl0ZWN0dXJzLCBlLmcuIEFSQyBtYXkgaGF2ZSBaT05FX0hJR0hN
RU0gYmVsb3cgWk9ORV9OT1JNQUwuIEZvcg0KPiArICogc3VjaCBjYXNlcyB3ZSBhbGxvdyBtYXhf
em9uZV9wZm4gc29ydGVkIGluIHRoZSBkZXNjZW5kaW5nIG9yZGVyDQo+ICsgKi8NCj4gK2Jvb2wg
X193ZWFrIGFyY2hfaGFzX2Rlc2NlbmRpbmdfbWF4X3pvbmVfcGZucyh2b2lkKQ0KPiArew0KPiAr
CXJldHVybiBmYWxzZTsNCj4gK30NCj4gKw0KPiAgLyoqDQo+ICAgKiBmcmVlX2FyZWFfaW5pdCAt
IEluaXRpYWxpc2UgYWxsIHBnX2RhdGFfdCBhbmQgem9uZSBkYXRhDQo+ICAgKiBAbWF4X3pvbmVf
cGZuOiBhbiBhcnJheSBvZiBtYXggUEZOcyBmb3IgZWFjaCB6b25lDQo+IEBAIC03MzI0LDcgKzcz
MzMsNyBAQCB2b2lkIF9faW5pdCBmcmVlX2FyZWFfaW5pdCh1bnNpZ25lZCBsb25nICptYXhfem9u
ZV9wZm4pDQo+ICB7DQo+ICAJdW5zaWduZWQgbG9uZyBzdGFydF9wZm4sIGVuZF9wZm47DQo+ICAJ
aW50IGksIG5pZCwgem9uZTsNCj4gLQlib29sIGRlc2NlbmRpbmcgPSBmYWxzZTsNCj4gKwlib29s
IGRlc2NlbmRpbmc7DQo+ICANCj4gIAkvKiBSZWNvcmQgd2hlcmUgdGhlIHpvbmUgYm91bmRhcmll
cyBhcmUgKi8NCj4gIAltZW1zZXQoYXJjaF96b25lX2xvd2VzdF9wb3NzaWJsZV9wZm4sIDAsDQo+
IEBAIC03MzMzLDE0ICs3MzQyLDcgQEAgdm9pZCBfX2luaXQgZnJlZV9hcmVhX2luaXQodW5zaWdu
ZWQgbG9uZyAqbWF4X3pvbmVfcGZuKQ0KPiAgCQkJCXNpemVvZihhcmNoX3pvbmVfaGlnaGVzdF9w
b3NzaWJsZV9wZm4pKTsNCj4gIA0KPiAgCXN0YXJ0X3BmbiA9IGZpbmRfbWluX3Bmbl93aXRoX2Fj
dGl2ZV9yZWdpb25zKCk7DQo+IC0NCj4gLQkvKg0KPiAtCSAqIFNvbWUgYXJjaGl0ZWN0dXJzLCBl
LmcuIEFSQyBtYXkgaGF2ZSBaT05FX0hJR0hNRU0gYmVsb3cNCj4gLQkgKiBaT05FX05PUk1BTC4g
Rm9yIHN1Y2ggY2FzZXMgd2UgYWxsb3cgbWF4X3pvbmVfcGZuIHNvcnRlZCBpbiB0aGUNCj4gLQkg
KiBkZXNjZW5kaW5nIG9yZGVyDQo+IC0JICovDQo+IC0JaWYgKE1BWF9OUl9aT05FUyA+IDEgJiYg
bWF4X3pvbmVfcGZuWzBdID4gbWF4X3pvbmVfcGZuWzFdKQ0KPiAtCQlkZXNjZW5kaW5nID0gdHJ1
ZTsNCj4gKwlkZXNjZW5kaW5nID0gYXJjaF9oYXNfZGVzY2VuZGluZ19tYXhfem9uZV9wZm5zKCk7
DQo+ICANCj4gIAlmb3IgKGkgPSAwOyBpIDwgTUFYX05SX1pPTkVTOyBpKyspIHsNCj4gIAkJaWYg
KGRlc2NlbmRpbmcpDQo+IA0K
WARNING: multiple messages have this Message-ID (diff)
From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
To: Mike Rapoport <rppt@kernel.org>, Guenter Roeck <linux@roeck-us.net>
Cc: Rich Felker <dalias@libc.org>,
"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
"x86@kernel.org" <x86@kernel.org>,
Michal Hocko <mhocko@kernel.org>,
"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
Max Filippov <jcmvbkbc@gmail.com>, Guo Ren <guoren@kernel.org>,
Ley Foon Tan <ley.foon.tan@intel.com>,
"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
"linux-riscv@lists.infradead.org"
<linux-riscv@lists.infradead.org>,
Greg Ungerer <gerg@linux-m68k.org>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
"linux-c6x-dev@linux-c6x.org" <linux-c6x-dev@linux-c6x.org>,
Baoquan He <bhe@redhat.com>, Jonathan Corbet <corbet@lwn.net>,
"linux-hexagon@vger.kernel.org" <linux-hexagon@vger.kernel.org>,
Helge Deller <deller@gmx.de>,
"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
Russell King <linux@armlinux.org.uk>,
"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
Mike Rapoport <rppt@linux.ibm.com>,
Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: [PATCH v2 17/20] mm: free_area_init: allow defining max_zone_pfn in descending order
Date: Tue, 5 May 2020 06:23:37 +0000 [thread overview]
Message-ID: <a0b20e15-fddb-aa9c-fd67-f1c8e735b4a4@synopsys.com> (raw)
In-Reply-To: <20200504153901.GM14260@kernel.org>
Hi Mike,
On 5/4/20 8:39 AM, Mike Rapoport wrote:
> On Sun, May 03, 2020 at 11:43:00AM -0700, Guenter Roeck wrote:
>> On Sun, May 03, 2020 at 10:41:38AM -0700, Guenter Roeck wrote:
>>> Hi,
>>>
>>> On Wed, Apr 29, 2020 at 03:11:23PM +0300, Mike Rapoport wrote:
>>>> From: Mike Rapoport <rppt@linux.ibm.com>
>>>>
>>>> Some architectures (e.g. ARC) have the ZONE_HIGHMEM zone below the
>>>> ZONE_NORMAL. Allowing free_area_init() parse max_zone_pfn array even it is
>>>> sorted in descending order allows using free_area_init() on such
>>>> architectures.
>>>>
>>>> Add top -> down traversal of max_zone_pfn array in free_area_init() and use
>>>> the latter in ARC node/zone initialization.
>>>>
>>>> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
>>>
>>> This patch causes my microblazeel qemu boot test in linux-next to fail.
>>> Reverting it fixes the problem.
>>>
>> The same problem is seen with s390 emulations.
>
> Yeah, this patch breaks some others as well :(
>
> My assumption that max_zone_pfn defines architectural limit for maximal
> PFN that can belong to a zone was over-optimistic. Several arches
> actually do that, but others do
>
> max_zone_pfn[ZONE_DMA] = MAX_DMA_PFN;
> max_zone_pfn[ZONE_NORMAL] = max_pfn;
>
> where MAX_DMA_PFN is build-time constrain and max_pfn is run time limit
> for the current system.
>
> So, when max_pfn is lower than MAX_DMA_PFN, the free_init_area() will
> consider max_zone_pfn as descending and will wrongly calculate zone
> extents.
>
> That said, instead of trying to create a generic way to special case
> ARC, I suggest to simply use the below patch instead.
Even for ARC it will be a bit more complicated. Highmem on ARC can be setup in 2
ways such that it is descending in one case, and ascending in other (w.r.t
"normal" mem) :-(
First some basic info about an ARC MMU based system
ARC logical address space (various addresses embedded in binaries)
- translated (0 to 0x6FFF_FFFF) - for userspace
- untranslated (0x8000_0000 to 0xFFFF_FFFF) - kernel
ARC Physical address space is typically from 0x8000_0000 to 0xF000_0000.
Above translated space maps here via MMU. Untranslated is implicitly mapped (no
MMU involved).
The physical address in turn maps to a Bus address / memory (done at the
inter-connect/NoC). Typically Physical 0x8000_0000 map to DDR 0
Now,
- HIGHMEM w/o PAE40 adds Physical address space 0 to 0x7FFF_FFFF.
- HIGHMEM with PAE40 uses physical address space from 0x1_0000_0000 upwards.
But then you could also have a system which has both of above so the bimodal up/dn
won't work.
While I appreciate the effort to reduce complexity, it seems the current way of
setting things up allows for more flexibility in specifying the system memory map.
PS: I haven't looked at your series too carefully, the mention of ARC caught my
attention :-) I guess I need to read it more carefully to understand.
>
> diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
> index 41eb9be1653c..386959bac3d2 100644
> --- a/arch/arc/mm/init.c
> +++ b/arch/arc/mm/init.c
> @@ -77,6 +77,11 @@ void __init early_init_dt_add_memory_arch(u64 base, u64 size)
> base, TO_MB(size), !in_use ? "Not used":"");
> }
>
> +bool arch_has_descending_max_zone_pfns(void)
> +{
> + return true;
> +}
> +
> /*
> * First memory setup routine called from setup_arch()
> * 1. setup swapper's mm @init_mm
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index b990e9734474..114f0e027144 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -7307,6 +7307,15 @@ static void check_for_memory(pg_data_t *pgdat, int nid)
> }
> }
>
> +/*
> + * Some architecturs, e.g. ARC may have ZONE_HIGHMEM below ZONE_NORMAL. For
> + * such cases we allow max_zone_pfn sorted in the descending order
> + */
> +bool __weak arch_has_descending_max_zone_pfns(void)
> +{
> + return false;
> +}
> +
> /**
> * free_area_init - Initialise all pg_data_t and zone data
> * @max_zone_pfn: an array of max PFNs for each zone
> @@ -7324,7 +7333,7 @@ void __init free_area_init(unsigned long *max_zone_pfn)
> {
> unsigned long start_pfn, end_pfn;
> int i, nid, zone;
> - bool descending = false;
> + bool descending;
>
> /* Record where the zone boundaries are */
> memset(arch_zone_lowest_possible_pfn, 0,
> @@ -7333,14 +7342,7 @@ void __init free_area_init(unsigned long *max_zone_pfn)
> sizeof(arch_zone_highest_possible_pfn));
>
> start_pfn = find_min_pfn_with_active_regions();
> -
> - /*
> - * Some architecturs, e.g. ARC may have ZONE_HIGHMEM below
> - * ZONE_NORMAL. For such cases we allow max_zone_pfn sorted in the
> - * descending order
> - */
> - if (MAX_NR_ZONES > 1 && max_zone_pfn[0] > max_zone_pfn[1])
> - descending = true;
> + descending = arch_has_descending_max_zone_pfns();
>
> for (i = 0; i < MAX_NR_ZONES; i++) {
> if (descending)
>
WARNING: multiple messages have this Message-ID (diff)
From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
To: Mike Rapoport <rppt@kernel.org>, Guenter Roeck <linux@roeck-us.net>
Cc: Rich Felker <dalias@libc.org>,
"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
"x86@kernel.org" <x86@kernel.org>,
Michal Hocko <mhocko@kernel.org>,
"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
Max Filippov <jcmvbkbc@gmail.com>, Guo Ren <guoren@kernel.org>,
Ley Foon Tan <ley.foon.tan@intel.com>,
"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
"linux-riscv@lists.infradead.org"
<linux-riscv@lists.infradead.org>,
Greg Ungerer <gerg@linux-m68k.org>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
linux-c6x-dev@linux-c
Subject: Re: [PATCH v2 17/20] mm: free_area_init: allow defining max_zone_pfn in descending order
Date: Tue, 5 May 2020 06:23:37 +0000 [thread overview]
Message-ID: <a0b20e15-fddb-aa9c-fd67-f1c8e735b4a4@synopsys.com> (raw)
In-Reply-To: <20200504153901.GM14260@kernel.org>
Hi Mike,
On 5/4/20 8:39 AM, Mike Rapoport wrote:
> On Sun, May 03, 2020 at 11:43:00AM -0700, Guenter Roeck wrote:
>> On Sun, May 03, 2020 at 10:41:38AM -0700, Guenter Roeck wrote:
>>> Hi,
>>>
>>> On Wed, Apr 29, 2020 at 03:11:23PM +0300, Mike Rapoport wrote:
>>>> From: Mike Rapoport <rppt@linux.ibm.com>
>>>>
>>>> Some architectures (e.g. ARC) have the ZONE_HIGHMEM zone below the
>>>> ZONE_NORMAL. Allowing free_area_init() parse max_zone_pfn array even it is
>>>> sorted in descending order allows using free_area_init() on such
>>>> architectures.
>>>>
>>>> Add top -> down traversal of max_zone_pfn array in free_area_init() and use
>>>> the latter in ARC node/zone initialization.
>>>>
>>>> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
>>>
>>> This patch causes my microblazeel qemu boot test in linux-next to fail.
>>> Reverting it fixes the problem.
>>>
>> The same problem is seen with s390 emulations.
>
> Yeah, this patch breaks some others as well :(
>
> My assumption that max_zone_pfn defines architectural limit for maximal
> PFN that can belong to a zone was over-optimistic. Several arches
> actually do that, but others do
>
> max_zone_pfn[ZONE_DMA] = MAX_DMA_PFN;
> max_zone_pfn[ZONE_NORMAL] = max_pfn;
>
> where MAX_DMA_PFN is build-time constrain and max_pfn is run time limit
> for the current system.
>
> So, when max_pfn is lower than MAX_DMA_PFN, the free_init_area() will
> consider max_zone_pfn as descending and will wrongly calculate zone
> extents.
>
> That said, instead of trying to create a generic way to special case
> ARC, I suggest to simply use the below patch instead.
Even for ARC it will be a bit more complicated. Highmem on ARC can be setup in 2
ways such that it is descending in one case, and ascending in other (w.r.t
"normal" mem) :-(
First some basic info about an ARC MMU based system
ARC logical address space (various addresses embedded in binaries)
- translated (0 to 0x6FFF_FFFF) - for userspace
- untranslated (0x8000_0000 to 0xFFFF_FFFF) - kernel
ARC Physical address space is typically from 0x8000_0000 to 0xF000_0000.
Above translated space maps here via MMU. Untranslated is implicitly mapped (no
MMU involved).
The physical address in turn maps to a Bus address / memory (done at the
inter-connect/NoC). Typically Physical 0x8000_0000 map to DDR 0
Now,
- HIGHMEM w/o PAE40 adds Physical address space 0 to 0x7FFF_FFFF.
- HIGHMEM with PAE40 uses physical address space from 0x1_0000_0000 upwards.
But then you could also have a system which has both of above so the bimodal up/dn
won't work.
While I appreciate the effort to reduce complexity, it seems the current way of
setting things up allows for more flexibility in specifying the system memory map.
PS: I haven't looked at your series too carefully, the mention of ARC caught my
attention :-) I guess I need to read it more carefully to understand.
>
> diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
> index 41eb9be1653c..386959bac3d2 100644
> --- a/arch/arc/mm/init.c
> +++ b/arch/arc/mm/init.c
> @@ -77,6 +77,11 @@ void __init early_init_dt_add_memory_arch(u64 base, u64 size)
> base, TO_MB(size), !in_use ? "Not used":"");
> }
>
> +bool arch_has_descending_max_zone_pfns(void)
> +{
> + return true;
> +}
> +
> /*
> * First memory setup routine called from setup_arch()
> * 1. setup swapper's mm @init_mm
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index b990e9734474..114f0e027144 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -7307,6 +7307,15 @@ static void check_for_memory(pg_data_t *pgdat, int nid)
> }
> }
>
> +/*
> + * Some architecturs, e.g. ARC may have ZONE_HIGHMEM below ZONE_NORMAL. For
> + * such cases we allow max_zone_pfn sorted in the descending order
> + */
> +bool __weak arch_has_descending_max_zone_pfns(void)
> +{
> + return false;
> +}
> +
> /**
> * free_area_init - Initialise all pg_data_t and zone data
> * @max_zone_pfn: an array of max PFNs for each zone
> @@ -7324,7 +7333,7 @@ void __init free_area_init(unsigned long *max_zone_pfn)
> {
> unsigned long start_pfn, end_pfn;
> int i, nid, zone;
> - bool descending = false;
> + bool descending;
>
> /* Record where the zone boundaries are */
> memset(arch_zone_lowest_possible_pfn, 0,
> @@ -7333,14 +7342,7 @@ void __init free_area_init(unsigned long *max_zone_pfn)
> sizeof(arch_zone_highest_possible_pfn));
>
> start_pfn = find_min_pfn_with_active_regions();
> -
> - /*
> - * Some architecturs, e.g. ARC may have ZONE_HIGHMEM below
> - * ZONE_NORMAL. For such cases we allow max_zone_pfn sorted in the
> - * descending order
> - */
> - if (MAX_NR_ZONES > 1 && max_zone_pfn[0] > max_zone_pfn[1])
> - descending = true;
> + descending = arch_has_descending_max_zone_pfns();
>
> for (i = 0; i < MAX_NR_ZONES; i++) {
> if (descending)
>
WARNING: multiple messages have this Message-ID (diff)
From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
To: Mike Rapoport <rppt@kernel.org>, Guenter Roeck <linux@roeck-us.net>
Cc: Rich Felker <dalias@libc.org>,
"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
"x86@kernel.org" <x86@kernel.org>,
Michal Hocko <mhocko@kernel.org>,
"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
Max Filippov <jcmvbkbc@gmail.com>, Guo Ren <guoren@kernel.org>,
"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
"linux-riscv@lists.infradead.org"
<linux-riscv@lists.infradead.org>,
Greg Ungerer <gerg@linux-m68k.org>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
"linux-c6x-dev@linux-c6x.org" <linux-c6x-dev@linux-c6x.org>,
Baoquan He <bhe@redhat.com>, Jonathan Corbet <corbet@lwn.net>,
"linux-hexagon@vger.kernel.org" <linux-hexagon@vger.kernel.org>,
Helge Deller <deller@gmx.de>,
"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
Russell King <linux@armlinux.org.uk>,
Ley Foon Tan <ley.foon.tan@intel.com>,
Mike Rapoport <rppt@linux.ibm.com>,
Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: [PATCH v2 17/20] mm: free_area_init: allow defining max_zone_pfn in descending order
Date: Tue, 5 May 2020 06:23:37 +0000 [thread overview]
Message-ID: <a0b20e15-fddb-aa9c-fd67-f1c8e735b4a4@synopsys.com> (raw)
In-Reply-To: <20200504153901.GM14260@kernel.org>
Hi Mike,
On 5/4/20 8:39 AM, Mike Rapoport wrote:
> On Sun, May 03, 2020 at 11:43:00AM -0700, Guenter Roeck wrote:
>> On Sun, May 03, 2020 at 10:41:38AM -0700, Guenter Roeck wrote:
>>> Hi,
>>>
>>> On Wed, Apr 29, 2020 at 03:11:23PM +0300, Mike Rapoport wrote:
>>>> From: Mike Rapoport <rppt@linux.ibm.com>
>>>>
>>>> Some architectures (e.g. ARC) have the ZONE_HIGHMEM zone below the
>>>> ZONE_NORMAL. Allowing free_area_init() parse max_zone_pfn array even it is
>>>> sorted in descending order allows using free_area_init() on such
>>>> architectures.
>>>>
>>>> Add top -> down traversal of max_zone_pfn array in free_area_init() and use
>>>> the latter in ARC node/zone initialization.
>>>>
>>>> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
>>>
>>> This patch causes my microblazeel qemu boot test in linux-next to fail.
>>> Reverting it fixes the problem.
>>>
>> The same problem is seen with s390 emulations.
>
> Yeah, this patch breaks some others as well :(
>
> My assumption that max_zone_pfn defines architectural limit for maximal
> PFN that can belong to a zone was over-optimistic. Several arches
> actually do that, but others do
>
> max_zone_pfn[ZONE_DMA] = MAX_DMA_PFN;
> max_zone_pfn[ZONE_NORMAL] = max_pfn;
>
> where MAX_DMA_PFN is build-time constrain and max_pfn is run time limit
> for the current system.
>
> So, when max_pfn is lower than MAX_DMA_PFN, the free_init_area() will
> consider max_zone_pfn as descending and will wrongly calculate zone
> extents.
>
> That said, instead of trying to create a generic way to special case
> ARC, I suggest to simply use the below patch instead.
Even for ARC it will be a bit more complicated. Highmem on ARC can be setup in 2
ways such that it is descending in one case, and ascending in other (w.r.t
"normal" mem) :-(
First some basic info about an ARC MMU based system
ARC logical address space (various addresses embedded in binaries)
- translated (0 to 0x6FFF_FFFF) - for userspace
- untranslated (0x8000_0000 to 0xFFFF_FFFF) - kernel
ARC Physical address space is typically from 0x8000_0000 to 0xF000_0000.
Above translated space maps here via MMU. Untranslated is implicitly mapped (no
MMU involved).
The physical address in turn maps to a Bus address / memory (done at the
inter-connect/NoC). Typically Physical 0x8000_0000 map to DDR 0
Now,
- HIGHMEM w/o PAE40 adds Physical address space 0 to 0x7FFF_FFFF.
- HIGHMEM with PAE40 uses physical address space from 0x1_0000_0000 upwards.
But then you could also have a system which has both of above so the bimodal up/dn
won't work.
While I appreciate the effort to reduce complexity, it seems the current way of
setting things up allows for more flexibility in specifying the system memory map.
PS: I haven't looked at your series too carefully, the mention of ARC caught my
attention :-) I guess I need to read it more carefully to understand.
>
> diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
> index 41eb9be1653c..386959bac3d2 100644
> --- a/arch/arc/mm/init.c
> +++ b/arch/arc/mm/init.c
> @@ -77,6 +77,11 @@ void __init early_init_dt_add_memory_arch(u64 base, u64 size)
> base, TO_MB(size), !in_use ? "Not used":"");
> }
>
> +bool arch_has_descending_max_zone_pfns(void)
> +{
> + return true;
> +}
> +
> /*
> * First memory setup routine called from setup_arch()
> * 1. setup swapper's mm @init_mm
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index b990e9734474..114f0e027144 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -7307,6 +7307,15 @@ static void check_for_memory(pg_data_t *pgdat, int nid)
> }
> }
>
> +/*
> + * Some architecturs, e.g. ARC may have ZONE_HIGHMEM below ZONE_NORMAL. For
> + * such cases we allow max_zone_pfn sorted in the descending order
> + */
> +bool __weak arch_has_descending_max_zone_pfns(void)
> +{
> + return false;
> +}
> +
> /**
> * free_area_init - Initialise all pg_data_t and zone data
> * @max_zone_pfn: an array of max PFNs for each zone
> @@ -7324,7 +7333,7 @@ void __init free_area_init(unsigned long *max_zone_pfn)
> {
> unsigned long start_pfn, end_pfn;
> int i, nid, zone;
> - bool descending = false;
> + bool descending;
>
> /* Record where the zone boundaries are */
> memset(arch_zone_lowest_possible_pfn, 0,
> @@ -7333,14 +7342,7 @@ void __init free_area_init(unsigned long *max_zone_pfn)
> sizeof(arch_zone_highest_possible_pfn));
>
> start_pfn = find_min_pfn_with_active_regions();
> -
> - /*
> - * Some architecturs, e.g. ARC may have ZONE_HIGHMEM below
> - * ZONE_NORMAL. For such cases we allow max_zone_pfn sorted in the
> - * descending order
> - */
> - if (MAX_NR_ZONES > 1 && max_zone_pfn[0] > max_zone_pfn[1])
> - descending = true;
> + descending = arch_has_descending_max_zone_pfns();
>
> for (i = 0; i < MAX_NR_ZONES; i++) {
> if (descending)
>
next prev parent reply other threads:[~2020-05-05 6:23 UTC|newest]
Thread overview: 227+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-29 12:11 [PATCH v2 00/20] mm: rework free_area_init*() funcitons Mike Rapoport
2020-04-29 12:11 ` [OpenRISC] " Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` [PATCH v2 01/20] mm: memblock: replace dereferences of memblock_region.nid with API calls Mike Rapoport
2020-04-29 12:11 ` [OpenRISC] " Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` [PATCH v2 02/20] mm: make early_pfn_to_nid() and related defintions close to each other Mike Rapoport
2020-04-29 12:11 ` [OpenRISC] " Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` [PATCH v2 03/20] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP option Mike Rapoport
2020-04-29 12:11 ` [OpenRISC] " Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-05-26 17:11 ` Catalin Marinas
2020-05-26 17:11 ` [OpenRISC] " Catalin Marinas
2020-05-26 17:11 ` Catalin Marinas
2020-05-26 17:11 ` Catalin Marinas
2020-05-26 17:11 ` Catalin Marinas
2020-05-26 17:11 ` Catalin Marinas
2020-04-29 12:11 ` [PATCH v2 04/20] mm: free_area_init: use maximal zone PFNs rather than zone sizes Mike Rapoport
2020-04-29 12:11 ` [OpenRISC] " Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` [PATCH v2 05/20] mm: use free_area_init() instead of free_area_init_nodes() Mike Rapoport
2020-04-29 12:11 ` [OpenRISC] " Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-05-26 17:13 ` Catalin Marinas
2020-05-26 17:13 ` [OpenRISC] " Catalin Marinas
2020-05-26 17:13 ` Catalin Marinas
2020-05-26 17:13 ` Catalin Marinas
2020-05-26 17:13 ` Catalin Marinas
2020-05-26 17:13 ` Catalin Marinas
2020-04-29 12:11 ` [PATCH v2 06/20] alpha: simplify detection of memory zone boundaries Mike Rapoport
2020-04-29 12:11 ` [OpenRISC] " Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` [PATCH v2 07/20] arm: " Mike Rapoport
2020-04-29 12:11 ` [OpenRISC] " Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` [PATCH v2 08/20] arm64: simplify detection of memory zone boundaries for UMA configs Mike Rapoport
2020-04-29 12:11 ` [OpenRISC] " Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-05-26 17:15 ` Catalin Marinas
2020-05-26 17:15 ` [OpenRISC] " Catalin Marinas
2020-05-26 17:15 ` Catalin Marinas
2020-05-26 17:15 ` Catalin Marinas
2020-05-26 17:15 ` Catalin Marinas
2020-05-26 17:15 ` Catalin Marinas
2020-04-29 12:11 ` [PATCH v2 09/20] csky: simplify detection of memory zone boundaries Mike Rapoport
2020-04-29 12:11 ` [OpenRISC] " Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` [PATCH v2 10/20] m68k: mm: " Mike Rapoport
2020-04-29 12:11 ` [OpenRISC] " Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` [PATCH v2 11/20] parisc: " Mike Rapoport
2020-04-29 12:11 ` [OpenRISC] " Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` [PATCH v2 12/20] sparc32: " Mike Rapoport
2020-04-29 12:11 ` [OpenRISC] " Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` [PATCH v2 13/20] unicore32: " Mike Rapoport
2020-04-29 12:11 ` [OpenRISC] " Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` [PATCH v2 14/20] xtensa: " Mike Rapoport
2020-04-29 12:11 ` [OpenRISC] " Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` [PATCH v2 15/20] mm: memmap_init: iterate over memblock regions rather that check each PFN Mike Rapoport
2020-04-29 12:11 ` [OpenRISC] " Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` [PATCH v2 16/20] mm: remove early_pfn_in_nid() and CONFIG_NODES_SPAN_OTHER_NODES Mike Rapoport
2020-04-29 12:11 ` [OpenRISC] " Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 14:17 ` Christoph Hellwig
2020-04-29 14:17 ` [OpenRISC] " Christoph Hellwig
2020-04-29 14:17 ` Christoph Hellwig
2020-04-29 14:17 ` Christoph Hellwig
2020-04-29 14:17 ` Christoph Hellwig
2020-04-29 14:33 ` Mike Rapoport
2020-04-29 14:33 ` [OpenRISC] " Mike Rapoport
2020-04-29 14:33 ` Mike Rapoport
2020-04-29 14:33 ` Mike Rapoport
2020-04-29 14:33 ` Mike Rapoport
2020-04-29 16:29 ` [PATCH v2.5 " Mike Rapoport
2020-04-29 16:29 ` [OpenRISC] " Mike Rapoport
2020-04-29 16:29 ` Mike Rapoport
2020-04-29 16:29 ` Mike Rapoport
2020-04-29 16:29 ` Mike Rapoport
2020-04-29 16:29 ` Mike Rapoport
2020-04-29 12:11 ` [PATCH v2 17/20] mm: free_area_init: allow defining max_zone_pfn in descending order Mike Rapoport
2020-04-29 12:11 ` [OpenRISC] " Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-05-03 17:41 ` Guenter Roeck
2020-05-03 17:41 ` [OpenRISC] " Guenter Roeck
2020-05-03 17:41 ` Guenter Roeck
2020-05-03 17:41 ` Guenter Roeck
2020-05-03 17:41 ` Guenter Roeck
2020-05-03 17:41 ` Guenter Roeck
2020-05-03 18:43 ` Guenter Roeck
2020-05-03 18:43 ` [OpenRISC] " Guenter Roeck
2020-05-03 18:43 ` Guenter Roeck
2020-05-03 18:43 ` Guenter Roeck
2020-05-03 18:43 ` Guenter Roeck
2020-05-03 18:43 ` Guenter Roeck
2020-05-04 15:39 ` Mike Rapoport
2020-05-04 15:39 ` [OpenRISC] " Mike Rapoport
2020-05-04 15:39 ` Mike Rapoport
2020-05-04 15:39 ` Mike Rapoport
2020-05-04 15:39 ` Mike Rapoport
2020-05-04 15:39 ` Mike Rapoport
2020-05-05 6:23 ` Vineet Gupta [this message]
2020-05-05 6:23 ` Vineet Gupta
2020-05-05 6:23 ` Vineet Gupta
2020-05-05 6:23 ` Vineet Gupta
2020-05-05 9:19 ` Mike Rapoport
2020-05-05 9:19 ` Mike Rapoport
2020-05-05 9:19 ` Mike Rapoport
2020-05-05 9:19 ` Mike Rapoport
2020-05-05 18:07 ` Vineet Gupta
2020-05-05 18:07 ` Vineet Gupta
2020-05-05 18:07 ` Vineet Gupta
2020-05-05 18:07 ` Vineet Gupta
2020-05-05 18:07 ` Vineet Gupta
2020-05-05 20:15 ` Mike Rapoport
2020-05-05 20:15 ` Mike Rapoport
2020-05-05 20:15 ` Mike Rapoport
2020-05-05 20:15 ` Mike Rapoport
2020-05-05 20:15 ` Mike Rapoport
2020-05-07 20:59 ` Mike Rapoport
2020-05-07 20:59 ` Mike Rapoport
2020-05-07 20:59 ` Mike Rapoport
2020-05-07 20:59 ` Mike Rapoport
2020-05-07 20:59 ` Mike Rapoport
2020-05-07 20:59 ` Mike Rapoport
2020-05-07 21:21 ` Vineet Gupta
2020-05-07 21:21 ` Vineet Gupta
2020-05-07 21:21 ` Vineet Gupta
2020-05-07 21:21 ` Vineet Gupta
2020-05-07 21:21 ` Vineet Gupta
2020-05-05 13:18 ` Guenter Roeck
2020-05-05 13:18 ` [OpenRISC] " Guenter Roeck
2020-05-05 13:18 ` Guenter Roeck
2020-05-05 13:18 ` Guenter Roeck
2020-05-05 13:18 ` Guenter Roeck
2020-05-05 13:18 ` Guenter Roeck
2020-05-05 13:45 ` Mike Rapoport
2020-05-05 13:45 ` [OpenRISC] " Mike Rapoport
2020-05-05 13:45 ` Mike Rapoport
2020-05-05 13:45 ` Mike Rapoport
2020-05-05 13:45 ` Mike Rapoport
2020-05-05 13:45 ` Mike Rapoport
2020-05-05 17:27 ` Vineet Gupta
2020-05-05 17:27 ` Vineet Gupta
2020-05-05 17:27 ` Vineet Gupta
2020-05-05 17:27 ` [OpenRISC] " Vineet Gupta
2020-05-05 17:27 ` Vineet Gupta
2020-05-05 17:27 ` Vineet Gupta
2020-05-05 17:27 ` Vineet Gupta
2020-05-05 17:27 ` Vineet Gupta
2020-04-29 12:11 ` [PATCH v2 18/20] mm: clean up free_area_init_node() and its helpers Mike Rapoport
2020-04-29 12:11 ` [OpenRISC] " Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` [PATCH v2 19/20] mm: simplify find_min_pfn_with_active_regions() Mike Rapoport
2020-04-29 12:11 ` [OpenRISC] " Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` [PATCH v2 20/20] docs/vm: update memory-models documentation Mike Rapoport
2020-04-29 12:11 ` [OpenRISC] " Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
2020-04-29 12:11 ` Mike Rapoport
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=a0b20e15-fddb-aa9c-fd67-f1c8e735b4a4@synopsys.com \
--to=vineet.gupta1@synopsys.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=catalin.marinas@arm.com \
--cc=dalias@libc.org \
--cc=gerg@linux-m68k.org \
--cc=guoren@kernel.org \
--cc=heiko.carstens@de.ibm.com \
--cc=jcmvbkbc@gmail.com \
--cc=ley.foon.tan@intel.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-c6x-dev@linux-c \
--cc=linux-doc@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mhocko@kernel.org \
--cc=rppt@kernel.org \
--cc=sparclinux@vger.kernel.org \
--cc=x86@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.