Messages in this thread | | | Date | Mon, 10 Jan 2005 10:13:07 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: Prezeroing V3 [1/4]: Allow request for zeroed memory |
| |
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 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/
| |