site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Dkim-signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=sasl; bh= aYwelKxzwPS6UW0Li8ZxpxfHKLE=; b=bJD4hODxGqDoUPzqEk/RTYWfPuuiraIH eZxQ2CdCFGxq0ICya3rpR1O/g4ImFnIItNzLBRPI32H4xr/Yp5eAPR57zc7n3OSM p/iQrEVH9SLDvnWGx4aUQYiIef3U7E/D2iPc7BJPe2olyTxbXQwHNxDkithX+PKw eMfKs11qBjo= Domainkey-signature: a=rsa-sha1; c=nofws; d=pobox.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= sasl; b=Zm0gST1qszHp5vU6O2aXUqlH/PKpzwDHAyvOQ3hi1PMhJ1CuJJpi9JS7 0dl6Zfc+or4WuzR3BlkZgTjqNkmBX+i+G2uSGsjGGNwvK5Uhi5yvXJYVYPKCTHw4 4bOiUWGFIm4aNgBu/eDYNR6BW62GJ4VVNPcDShdJ9tqiQGAMBss= On Nov 8, 2009, at 11:31 AM, Joel Reymont wrote:
I reboot and run Firefox using the same arguments but get completely different page-in patterns every time. Why does this happen and how does this work?
How does the VFS determine the pages to fetch and the number of pages?
I'll let a kernel expert reply. There is some speculative read-ahead, the amount of which was increased in SnowLeopard. It is dependent on the system resources available and is likely to keep changing from release to release. When mapping libraries dyld issues asynchronous read requests for pages likely to be useful soonish. This includes LINKEDIT (needed for the dynamic linking process) and some parts of TEXT and DATA. This might cause some run-to-run variation between the on-demand reads and those speculative reads. Is Firefox/Minefield still single-threaded by the time your measurements are captured ? If not this could also lead to run-to-run variations.
I'm trying to optimize disk access during cold startup of Firefox and I thought I'd reorder the symbols in the dylib by time. I determined that the function call chain during startup is A, B, C, D, E, F. I assumed that by ordering the symbols this way I'll get sequential disk access which doesn't seem to be the case.
That's the recommended symbol ordering strategy. Do you see that order being stable across all runs ?
I monitor page-ins using a simple dtrace script [1]. I then translate these page-ins to actual segments and sections of the XUL dynamic library using the output from 'size -m -l XUL'.
One run may give me (head -10 ...)
__LINKEDIT, __symtab = 2 pages, 5016 pages in __LINKEDIT, __symtab = 2 pages, 5018 pages in __DATA, __const = 4 pages, 4850 pages in __DATA, __const = 4 pages, 4854 pages in __DATA, __const = 4 pages, 4858 pages in __DATA, __const = 4 pages, 4862 pages in __DATA, __const = 4 pages, 4866 pages in
whereas another run
__LINKEDIT, __symtab = 2 pages, 5016 pages in __DATA, __const = 5 pages, 4921 pages in __DATA, __const = 6 pages, 4956 pages in __DATA, __data = 7 pages, 4998 pages in __TEXT, __const = 40 pages, 256 pages in __TEXT, __cstring = 44 pages, 307 pages in __TEXT, __text = 73 pages, 2390 pages in
Where in the kernel is the logic that's applied here and what's the proper way to optimize my disk access?
Ordering by first access is your best bet. Eric
Thanks, Joel
[1] xul-pageins.d
fbt::vnode_pagein:entry { self->v_name = stringof(((vnode_t)arg0)->v_name); }
fbt::vnode_pagein:entry /self->v_name == "XUL"/ { printf("vnode_pagein: %s, offset: %u, size: %u\n", self->v_name, arg3, arg4); }
--- firefox for android! http://wagerlabs.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/eric.gouriou%40pobox.com
This email sent to eric.gouriou@pobox.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com