Re: First slow, then fast
Re: First slow, then fast
- Subject: Re: First slow, then fast
- From: James Quick <email@hidden>
- Date: Sun, 3 Aug 2003 23:00:15 -0400
On Sunday, August 3, 2003, at 08:51 PM, Lorenzo wrote:
Hi,
thank you for replying.
Do you really think the system puts the data into the cache?
IF so, how does my app knows that the data it needs at the second
search are
the same data contained in the cache?
Or did you mean the function is in the cache?
May you please let me understand?
And up above, is a way to make the first search as fast as the next
searches?
Although their are some significant difference between Darwin, and the
other
BSDs, the basic strategies for filesystem access are pretty much the
same.
All disk access, whether directly memory mapped via a call like mmap()
or
performed via read() and writes, passes through the same interface. The
I/O is also independent of file system type, whether it's ufs, hfs+,
cd, doesn't
matter.
As your process, walks through the file system, it is asking for
information about
file system objects. Each of these is associated with something called
a vnode.
Each disk, mount point, directory, file, the works, gets mapped onto a
vnode after
being read from disk, and parsed by a file system driver. The OS
mantains reference
counters in each vnode to keep track of how many processes are
referring to them.
So in a nutshell the vnode subsystem keeps track of objects on disk.
Another piece of the kernel is keeping track of the memory in the
system using
the vm subsystem. It maintains information about each page of memory
and has map of the virtual memory address space of each process. Each
memory object in a process's virtual memory address space, has size,
permissions, etc. It also has references to physical pages of memory
which have already been loaded or initialized by the vm subsystem.
The virtual memory subsystem and disk subsystem are intimately
connected, here.
Given a vnode and offset you can determine where in real memory it is
to
be found. Each pace of physical memory that is mapped to an object on
disk
refers to the vnode it belongs to so you can also go quickly from a
page in
to a vnode and offset.
Finally, it is a lazy system. Since all disk access goes through it,
the system
doesn't have to care how old the information is, it knows if the
contents are still valid.
Thus, even when no process has an active reference to memory whose
contents
were loaded from disk, the page can hang around for a long time. Sure,
it's
on a free list, it could be reused for something else, but under
normal, that
might not happen for a very long time. So, after you've done this
search
once, most if not of your subsequent requests for pages on disk, don't
have
to go to disk at all. And after reading data from the page to identify
the
next disk object (directory, file block, etc.) it has already been
converted
from its on-disk representation to a vnode, so when you ask for that
vnode
be found, it's already there as well.
When you think of cache, I bet you are thinking of toy oses, which
might reserve
10 or 20 meg for caching disk accesses. To the VM subsystem under BSD
and
Mach (which are related very closely) memory is memory, disk is disk.
and the vm
subsystem marries the two. It's not like it reserves some amount for
disk caching,
some amount for each program.
p.s. a bit trivia.
The vm subsystem in OSX derives in mostly from the work of someone whose
name you should find familiar. Back in the 80s and early 90s it was
used in a new
vm subsystem in BSD Unix, which spawned FreeBSD, OpenBSD, et al. Also
back
in the 80s, a mach, BSD hybrid called NeXTStep, obviously used this
approach.
The tree has merged together by bringing parts of the FreeBSD and
OpenStep code
bases back together in Darwin/Macos X.
Here are a few lines from vm_map.h in FreeBSD 5.1.
* @(#)vm_map.h 8.9 (Berkeley) 5/17/95
*
* Copyright (c) 1987, 1990 Carnegie-Mellon University.
* All rights reserved.
*
* Authors: Avadis Tevanian, Jr., Michael Wayne Young
* $FreeBSD: src/sys/vm/vm_map.h,v 1.97 2003/03/12 23:13:16 das Exp $
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.