Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
Re: vfs, ubc and pre-fetching on snow leopard
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: vfs, ubc and pre-fetching on snow leopard



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      (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >vfs, ubc and pre-fetching on snow leopard (From: Joel Reymont <email@hidden>)



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

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.