| Message ID | 1364184674-13798-6-git-send-email-iamjoonsoo.kim@lge.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Mar 25, 2013 at 01:11:13PM +0900, Joonsoo Kim wrote: > nobootmem use max_low_pfn for computing boundary in free_all_bootmem() > So we need proper value to max_low_pfn. > > But, there is some difficulty related to max_low_pfn. max_low_pfn is used > for two meanings in various architectures. One is for number of pages > in lowmem and the other is for maximum lowmem pfn. Now, in ARM, it is used > as number of pages in lowmem. You can get more information in below link. > http://lwn.net/Articles/543408/ > http://lwn.net/Articles/543424/ > > As I investigated, architectures which use max_low_pfn as maximum pfn are > more than others, so to change meaning of max_low_pfn to maximum pfn > is preferable solution to me. This patch change max_low_pfn as maximum > lowmem pfn in ARM. In addition, min_low_pfn, max_pfn is assigned according > to this criteria. > > There is no real user for max_low_pfn except block/blk-setting.c and > blk-setting.c assume that max_low_pfn is maximum lowmem pfn, > so this patch may not harm anything. This will need some very rigorous testing before it can go into mainline.
Hello, Russell. On Mon, Mar 25, 2013 at 09:48:16AM +0000, Russell King - ARM Linux wrote: > On Mon, Mar 25, 2013 at 01:11:13PM +0900, Joonsoo Kim wrote: > > nobootmem use max_low_pfn for computing boundary in free_all_bootmem() > > So we need proper value to max_low_pfn. > > > > But, there is some difficulty related to max_low_pfn. max_low_pfn is used > > for two meanings in various architectures. One is for number of pages > > in lowmem and the other is for maximum lowmem pfn. Now, in ARM, it is used > > as number of pages in lowmem. You can get more information in below link. > > http://lwn.net/Articles/543408/ > > http://lwn.net/Articles/543424/ > > > > As I investigated, architectures which use max_low_pfn as maximum pfn are > > more than others, so to change meaning of max_low_pfn to maximum pfn > > is preferable solution to me. This patch change max_low_pfn as maximum > > lowmem pfn in ARM. In addition, min_low_pfn, max_pfn is assigned according > > to this criteria. > > > > There is no real user for max_low_pfn except block/blk-setting.c and > > blk-setting.c assume that max_low_pfn is maximum lowmem pfn, > > so this patch may not harm anything. > > This will need some very rigorous testing before it can go into mainline. There is no attention from others to this patchset. :) Do you have any plan to test this? What I can do best is just to run this patchset on my platform. Would you guide me how to go into mainline for this patchset. Thanks. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
Joonsoo, On Monday 25 March 2013 12:11 AM, Joonsoo Kim wrote: > nobootmem use max_low_pfn for computing boundary in free_all_bootmem() > So we need proper value to max_low_pfn. > > But, there is some difficulty related to max_low_pfn. max_low_pfn is used > for two meanings in various architectures. One is for number of pages > in lowmem and the other is for maximum lowmem pfn. Now, in ARM, it is used > as number of pages in lowmem. You can get more information in below link. > http://lwn.net/Articles/543408/ > http://lwn.net/Articles/543424/ > > As I investigated, architectures which use max_low_pfn as maximum pfn are > more than others, so to change meaning of max_low_pfn to maximum pfn > is preferable solution to me. This patch change max_low_pfn as maximum > lowmem pfn in ARM. In addition, min_low_pfn, max_pfn is assigned according > to this criteria. > > There is no real user for max_low_pfn except block/blk-setting.c and > blk-setting.c assume that max_low_pfn is maximum lowmem pfn, > so this patch may not harm anything. > > Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com> > I have been also carrying similar patch as yours in an attempt to make LPAE kernel work on ARM. Your patch carries better description, so will your version and include in my series which I plan to post on the list after some more testing. Will copy you. The changes are very similar to your series. Regards, Santosh
On Mon, Jul 01, 2013 at 10:14:45AM -0400, Santosh Shilimkar wrote: > Joonsoo, > > On Monday 25 March 2013 12:11 AM, Joonsoo Kim wrote: > > nobootmem use max_low_pfn for computing boundary in free_all_bootmem() > > So we need proper value to max_low_pfn. > > > > But, there is some difficulty related to max_low_pfn. max_low_pfn is used > > for two meanings in various architectures. One is for number of pages > > in lowmem and the other is for maximum lowmem pfn. Now, in ARM, it is used > > as number of pages in lowmem. You can get more information in below link. > > http://lwn.net/Articles/543408/ > > http://lwn.net/Articles/543424/ > > > > As I investigated, architectures which use max_low_pfn as maximum pfn are > > more than others, so to change meaning of max_low_pfn to maximum pfn > > is preferable solution to me. This patch change max_low_pfn as maximum > > lowmem pfn in ARM. In addition, min_low_pfn, max_pfn is assigned according > > to this criteria. > > > > There is no real user for max_low_pfn except block/blk-setting.c and > > blk-setting.c assume that max_low_pfn is maximum lowmem pfn, > > so this patch may not harm anything. > > > > Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com> > > > I have been also carrying similar patch as yours in an attempt > to make LPAE kernel work on ARM. Your patch carries better > description, so will your version and include in my series > which I plan to post on the list after some more testing. > Will copy you. The changes are very similar to your series. Okay! Thanks. > > Regards, > Santosh > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c index 049414a..873f4ca 100644 --- a/arch/arm/mm/init.c +++ b/arch/arm/mm/init.c @@ -423,12 +423,10 @@ void __init bootmem_init(void) * This doesn't seem to be used by the Linux memory manager any * more, but is used by ll_rw_block. If we can get rid of it, we * also get rid of some of the stuff above as well. - * - * Note: max_low_pfn and max_pfn reflect the number of _pages_ in - * the system, not the maximum PFN. */ - max_low_pfn = max_low - PHYS_PFN_OFFSET; - max_pfn = max_high - PHYS_PFN_OFFSET; + min_low_pfn = min; + max_low_pfn = max_low; + max_pfn = max_high; } static inline int free_area(unsigned long pfn, unsigned long end, char *s) @@ -544,7 +542,7 @@ static void __init free_unused_memmap(struct meminfo *mi) static void __init free_highpages(void) { #ifdef CONFIG_HIGHMEM - unsigned long max_low = max_low_pfn + PHYS_PFN_OFFSET; + unsigned long max_low = max_low_pfn; struct memblock_region *mem, *res; /* set highmem page free */
nobootmem use max_low_pfn for computing boundary in free_all_bootmem() So we need proper value to max_low_pfn. But, there is some difficulty related to max_low_pfn. max_low_pfn is used for two meanings in various architectures. One is for number of pages in lowmem and the other is for maximum lowmem pfn. Now, in ARM, it is used as number of pages in lowmem. You can get more information in below link. http://lwn.net/Articles/543408/ http://lwn.net/Articles/543424/ As I investigated, architectures which use max_low_pfn as maximum pfn are more than others, so to change meaning of max_low_pfn to maximum pfn is preferable solution to me. This patch change max_low_pfn as maximum lowmem pfn in ARM. In addition, min_low_pfn, max_pfn is assigned according to this criteria. There is no real user for max_low_pfn except block/blk-setting.c and blk-setting.c assume that max_low_pfn is maximum lowmem pfn, so this patch may not harm anything. Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>