From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753947AbbICKa3 (ORCPT ); Thu, 3 Sep 2015 06:30:29 -0400 Received: from mailout4.samsung.com ([203.254.224.34]:43460 "EHLO mailout4.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753876AbbICKaD (ORCPT ); Thu, 3 Sep 2015 06:30:03 -0400 X-AuditID: cbfee68d-f79106d00000728c-ef-55e8212974ea From: Yongtaek Lee To: Russell King Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Nicolas Pitre , ytk.lee@samsung.com Subject: [PATCH] ARM: fix bug which lowmem size is limited to 760MB Date: Thu, 03 Sep 2015 19:30:33 +0900 Message-id: <1441276233-14566-1-git-send-email-ytk.lee@samsung.com> X-Mailer: git-send-email 1.7.9 In-reply-to: <20150903091044.GW21084@n2100.arm.linux.org.uk> References: <20150903091044.GW21084@n2100.arm.linux.org.uk> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsVy+t8zPV1NxRehBtM3K1hsenyN1eLyrjls Frcv81p8evaP3eLxem4HVo+W5h42jzvX9rB5bF5S79G3ZRWjx+dNcgGsUVw2Kak5mWWpRfp2 CVwZl07MZiw4LVCxcslBtgbGfzxdjJwcEgImEsuPTWOEsMUkLtxbz9bFyMUhJLCSUWLH04lM MEVTpi1ihEjMYpQ4uesAlPMDqOp+KwtIFZuAhsTOzqVgtoiApsSpxReZQWxmgXZGia2fNUBs YQFniedPP4BNZRFQlWi5fg9sNS9QfMHlo2wQ2+QkOnu/gcU5BWwkfk/7C1YvJGAt0TjjDNhi CYF2dol563azQwwSkPg2+RDQYg6ghKzEpgPMEHMkJQ6uuMEygVF4ASPDKkbR1ILkguKk9CJD veLE3OLSvHS95PzcTYyQcO7dwXj7gPUhRgEORiUe3o1ML0KFWBPLiitzDzGaAm2YyCwlmpwP jJq8knhDYzMjC1MTU2Mjc0szJXFeRamfwUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYJ33f nGkhtWNZdOaK1YtDJ2iJ7vv1JeP+A5/nYo9SpSd/MeH98GwVi8Phu+lbVCcaKH/N4tk05eTv zSEp36Un6ehd+iQSlW3JtWWeEKd5+NLnWy4e7LHknHO/1p+nekl5xJQ8m6UeDmpVSrvm+2WU p79iifs94a9p8sU5F1OqT/DfP77s5c6TJ5RYijMSDbWYi4oTAZgUbAhiAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsVy+t9jQV1NxRehBh0HZSw2Pb7GanF51xw2 i9uXeS0+PfvHbvF4PbcDq0dLcw+bx51re9g8Ni+p9+jbsorR4/MmuQDWqAZGm4zUxJTUIoXU vOT8lMy8dFsl7+B453hTMwNDXUNLC3MlhbzE3FRbJRefAF23zByg1UoKZYk5pUChgMTiYiV9 O0wTQkPcdC1gGiN0fUOC4HqMDNBAwjrGjEsnZjMWnBaoWLnkIFsD4z+eLkZODgkBE4kp0xYx QthiEhfurWfrYuTiEBKYxShxctcBRgjnB6PEjvutLCBVbAIaEjs7l4LZIgKaEqcWX2QGsZkF 2hkltn7WALGFBZwlnj/9wARiswioSrRcvwe2gRcovuDyUTaIbXISnb3fwOKcAjYSv6f9BasX ErCWaJxxhnECI+8CRoZVjBKpBckFxUnpuUZ5qeV6xYm5xaV56XrJ+bmbGMEx80x6B+PhXe6H GAU4GJV4eCfMfh4qxJpYVlyZe4hRgoNZSYQ35Q1QiDclsbIqtSg/vqg0J7X4EKMp0GETmaVE k/OB8ZxXEm9obGJmZGlkZmxibmysJM4ru/JZqJBAemJJanZqakFqEUwfEwenVANjnbX2oimz H/F8W8B4Xnhy9os6iysBr2MLfv79/4OnT9e9SqyjqHblisxdZzRcc9/4GfNlxHRp/jAonlV9 eA3/868XPfMOLf/7Y2ZrbqLZM8VZVt9+X8z/s3zd9gcnrEwu9GYK94SbuMxeOqPk7QOxz+es Dv8/ed6+epLyQaMii+6TtRt3ckQcUGIpzkg01GIuKk4EAOnuuRqvAgAA DLP-Filter: Pass X-MTR: 20000000000000000@CPGS X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Wrong, there is no such "rule". > If we apply that rule, then if you have 1GB of RAM, it will fill from > 0xc0000000 to 0xffffffff inclusive. There will be _zero_ bytes of > vmalloc space. There will be _zero_ bytes of IO mappings. There won't > even be a vectors page, so the kernel _will_ crash on the first exception. > The "rule" you think exists doesn't because it is wrong. I am sorry disturb you again. I am confusing after reading your comment. So i summarize my opinion again. Current status. 768MB, no CONFIG_HIGHMEM and no vmalloc=size lowmem : 0MB ~ 760MB vmalloc : 768MB ~ VMALLOC_END => waste 8MB because 760MB ~ 768MB is hole 1GB, no CONFIG_HIGHMEM and no vmalloc=size lowmem : 0MB ~ 760MB vmalloc : 768MB ~ VMALLOC_END => waste 264MB, so we need to enable CONFIG_HIGHMEM to use full memory. highmem : 264MB if enable CONFIG_HIGHMEM after applying patch. 768MB, no CONFIG_HIGHMEM and no vmalloc=size lowmem : 0MB ~ 768MB vmalloc : 776MB ~ VMALLOC_END => use 768MB fully 1GB, no CONFIG_HIGHMEM and no vmalloc=size lowmem : 0MB ~ 768MB vmalloc : 776MB ~ VMALLOC_END => waste 256MB, so we need to enable CONFIG_HIGHMEM to use full memory. highmem : 256MB if enable CONFIG_HIGHMEM => it will not fill from 0xc0000000 to 0xffffffff My opinion is not that vmalloc area size should be changed for all cases(512M, 768M, 1GB, 2GB, etc.). If we change default value from 240MB to 232MB, it could covor all cases without any other changes so that i have suggested this patch. As we already talked there are 3 cases with 768MB 1. live with the truncation => waste 8MB so that it will not be acceptable. 2. enable CONFIG_HIGHMEM => mm point of view it could make overhead because there is only 8MB(very small) in highmem. 3. set vmalloc size manually => I already mentioned it could fix issue but if default value is suitable then it is needless. Anyway please think again which size is more efficient for all cases. If you still think this patch is not acceptable i will accept your decision. Thank you for your comment.