Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
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 email@example.com (guest, #38022)
Posted Feb 26, 2009 20:17 UTC (Thu) by bluefoxicy (guest, #25366)
Posted Feb 27, 2009 1:21 UTC (Fri) by jzbiciak (✭ supporter ✭, #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 firstname.lastname@example.org (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 © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds