Re: vfs, ubc and pre-fetching on snow leopard
Re: vfs, ubc and pre-fetching on snow leopard
- Subject: Re: vfs, ubc and pre-fetching on snow leopard
- From: Eric Gouriou <email@hidden>
- Date: Sun, 8 Nov 2009 20:55:06 -0800
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