From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 10 Jan 2005 10:13:07 -0800 (PST) From: Linus Torvalds Subject: Re: Prezeroing V3 [1/4]: Allow request for zeroed memory In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Christoph Lameter Cc: Hugh Dickins , Andrew Morton , "David S. Miller" , linux-ia64@vger.kernel.org, linux-mm@kvack.org, Linux Kernel Development List-ID: On Mon, 10 Jan 2005, Christoph Lameter wrote: > > Yes. Right my ia64 centric vision got me again. Thanks for all the other > patches that were posted. I hope this is now all cleared up? Hmm.. I fixed things up, but I didn't exactly do it like the posted patches. Currently the BK tree - doesn't use __GFP_ZERO with anonymous user-mapped pages (which is what you wrote this whole thing for ;) Potential fix: declare a per-architecture "alloc_user_highpage(vaddr)" that does the proper magic on virtually indexed machines, and on others it just does a "alloc_page(GFP_HIGHUSER | __GFP_ZERO)". - verifies that nobody ever asks for a HIGHMEM allocation together with __GFP_ZERO (nobody does - a quick grep shows that 99% of all uses are statically clearly fine (there's a few HIGHMEM zero-page users, but they are all GFP_KERNEL or similar), with just two special cases: - get_zeroed_page() - which can't use HIGHMEM anyway - shm.c does "mapping_gfp_mask(inode->i_mapping) | __GFP_ZERO" and that's fine because while the mapping gfp masks may lack GFP_FS and GFP_IO, they are always supposed to be ok with waiting. - moves "kernel_map_pages()" into "prep_new_page()" to fix the DEBUG_PAGEALLOC issue (Chris Wright). So that should take care of the known problems. Linus -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: aart@kvack.org