You can use it to zero the page and not touch CPU cache.
Speeding up the page allocator
Posted Feb 26, 2009 12:09 UTC (Thu) by nix (subscriber, #2304)
Posted Feb 26, 2009 14:35 UTC (Thu) by firstname.lastname@example.org (guest, #38022)
Posted Feb 26, 2009 20:17 UTC (Thu) by bluefoxicy (guest, #25366)
Posted Feb 27, 2009 1:21 UTC (Fri) by jzbiciak (subscriber, #5246)
While it's true that zeroing all freed pages is a bad idea, keeping a pool of freed pages that's refilled during idle periods isn't so crazy. I believe the Windows NT kernel does something along those lines. You do end up putting more code in the fast-path to detect whether the "prezeroed pool" is non-empty, and it only applies to GFP_ZERO pages anyway, so I suspect it ends up not being a win under Linux.
Mel's patches bring a noticeable speedup at the benchmark level, and suggest to me that GFP_ZERO pages are not the most numerous allocations in the system. This makes intuitive sense--most allocations back other higher-level allocators in the kernel and/or provide buffer space that's about to be filled. There's no reason to zero it. Complicating those allocations for a minor speedup in GFP_ZERO allocations seems misplaced.
Posted Feb 27, 2009 10:26 UTC (Fri) by email@example.com (guest, #38022)
Posted Feb 27, 2009 23:14 UTC (Fri) by nix (subscriber, #2304)
IIRC the zero page was removed from the kernel because zeroing pages was
faster than doing pagetable tricks to share a single zero page. Pagetable
manipulation is particularly expensive, but even so...
we have /dev/zero, why not use the hardware implementation?
Posted Mar 4, 2009 8:03 UTC (Wed) by xoddam (subscriber, #2322)
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds