lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 20 Nov 2012 11:20:19 +0800 From: Jaegeuk Hanse <jaegeuk.hanse@...il.com> To: Jiang Liu <jiang.liu@...wei.com> CC: Jiang Liu <liuj97@...il.com>, Andrew Morton <akpm@...ux-foundation.org>, Wen Congyang <wency@...fujitsu.com>, David Rientjes <rientjes@...gle.com>, Maciej Rutecki <maciej.rutecki@...il.com>, Chris Clayton <chris2553@...glemail.com>, "Rafael J . Wysocki" <rjw@...k.pl>, Mel Gorman <mgorman@...e.de>, Minchan Kim <minchan@...nel.org>, KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>, Michal Hocko <mhocko@...e.cz>, Jianguo Wu <wujianguo@...wei.com>, linux-mm@...ck.org, linux-kernel@...r.kernel.org Subject: Re: [RFT PATCH v1 0/5] fix up inaccurate zone->present_pages On 11/20/2012 10:43 AM, Jiang Liu wrote: > On 2012-11-20 10:13, Jaegeuk Hanse wrote: >> On 11/19/2012 12:07 AM, Jiang Liu wrote: >>> The commit 7f1290f2f2a4 ("mm: fix-up zone present pages") tries to >>> resolve an issue caused by inaccurate zone->present_pages, but that >>> fix is incomplete and causes regresions with HIGHMEM. And it has been >>> reverted by commit >>> 5576646 revert "mm: fix-up zone present pages" >>> >>> This is a following-up patchset for the issue above. It introduces a >>> new field named "managed_pages" to struct zone, which counts pages >>> managed by the buddy system from the zone. And zone->present_pages >>> is used to count pages existing in the zone, which is >>> spanned_pages - absent_pages. >>> >>> But that way, zone->present_pages will be kept in consistence with >>> pgdat->node_present_pages, which is sum of zone->present_pages. >>> >>> This patchset has only been tested on x86_64 with nobootmem.c. So need >>> help to test this patchset on machines: >>> 1) use bootmem.c >> If only x86_32 use bootmem.c instead of nobootmem.c? How could I confirm it? > Hi Jaegeuk, > Thanks for review this patch set. > Currently x86/x86_64/Sparc have been converted to use nobootmem.c, > and other Arches still use bootmem.c. So need to test it on other Arches, > such as ARM etc. Yesterday we have tested it patchset on an Itanium platform, > so bootmem.c should work as expected too. Hi Jiang, If there are any codes changed in x86/x86_64 to meet nobootmem.c logic? I mean if remove config NO_BOOTMEM def_bool y in arch/x86/Kconfig, whether x86/x86_64 can take advantage of bootmem.c or not. Regards, Jaegeuk > Thanks! > Gerry > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists