Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: zero filling pages

I have an observation about this entire discussion, from the vantage point of someone who's been around OS guts in various forms since 1980...

Now I may be showing my age, but in the Olde Days, since zero-filling was (and still is) SUCH an important part of virtual memory page creation, systems like the VAX, the Alpha, the PDP-10, and many others sported hardware assistance for the zero-filling operation.

In other words, the hardware MMU (or the "pager" as us olde folkes would call it) would be told: "Create n pages and map them at address so-and-so", and the pager would go off and do so in hardware, and would notify the processor via an interrupt when it was done. Upon receipt of the interrupt, the VM routines would then go do the tedious mucking about with the page tables to reflect the newly-mapped pristine pages and then (finally!) return control to the user program.

In the earliest timesharing systems -- before hardware paging assist -- allocating new memory to a process took MUCH more time, because the swapper (predecessor to VM) had to explicitly write the zeroes itself! Main memory, consisting of three-dimensional arrays of magnetic cores -- "core memory" -- was MUCH slower than today's as well. 1.2-1.5 us per access was typical. Thus, zeroing a freshly-allocated memory page was very costly -- enough of a cost that it was measured. The then-equivalent of UNIX "top" had a "Core Zeroing Time" statistic that was watched carefully to ensure that processes weren't grabbing and releasing memory inefficiently.

If, as I suspect, the PPC (like every other CPU with a real MMU these days) can do memory zeroing in hardware, then the cost of that zeroing is a very small fraction of the time the system spends when your code does that first access. The rest of the time is spent in the overhead of mapping the virtual page to a real one, and all the gyrations that the VM subsystem goes through to do that in a way that manages memory most efficiently.

Bottom line: memory zeroing time is the very least of your reasons for the delay you're seeing. The bulk of the time is used in the overhead of managing the page tables, free page lists, and other data structures that have to be updated when new memory is mapped to a process.

Just two cents from someone who's been around these contraptions for far too long...

John Francini

--
----
John Francini <mailto:email@hidden>
+---------------------------------------------------------------------------+
| "I have come to the conclusion that one useless man is called a disgrace; |
| that two are called a law firm; and that three or more become a Congress.|
| And by God I have had _this_ Congress!" |
| -- John Adams |
+---------------------------------------------------------------------------+
_______________________________________________
darwin-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-development
Do not post admin requests to the list. They will be ignored.
References: 
 >Re: zero filling pages (From: Nat! <email@hidden>)
 >Re: zero filling pages (From: Ed Wynne <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.