Re: bypassing unified buffer cache?
Re: bypassing unified buffer cache?
- Subject: Re: bypassing unified buffer cache?
- From: Michael Smith <email@hidden>
- Date: Sat, 29 Jul 2006 13:54:55 -0700
On Jul 29, 2006, at 12:42 PM, Jonas Maebe wrote:
On 26 Jul 2006, at 22:21, Quinn wrote:
Also, for maximum effectiveness, you should ensure that your disk
I/Os are to a page aligned buffer, at a page aligned offset with
the file, and are an even multiple of a page in length.
A similar question just popped up on perfoptimization-dev. If
Microsoft and Adobe aren't filing bugs over this, it might
nevertheless be interesting for some Apple engineers evaluate the
way the cache flushing daemon (update) behaves, since it's
apparently killing performance for various apps (possibly including
things like Entourage, which I think should not require something
like F_NOCACHE for its mail database).
See http://lists.apple.com/archives/perfoptimization-dev/2006/Jul/
msg00047.html and follow-ups, in particular http://lists.apple.com/
archives/perfoptimization-dev/2006/Jul/msg00056.html and http://
lists.apple.com/archives/perfoptimization-dev/2006/Jul/msg00057.html
Without having a chance to analyse the actual example, I think you're
blowing this a little out of proportion.
It's quite difficult to generate "2-3 minutes" worth of dirty file
data without having any of it pushed out, and the message claiming
that dirty data is pushed synchronously every 30 seconds is
completely incorrect.
It *is* possible to find yourself blocked waiting for data to be
flushed if you attempt to flush twice in a row; the second flush
request wants the same lock that is held by the flush operation that
was kicked off by the first request. This is by design, making it
possible to synchronously wait for an asynchronous flush, however
this operation is only per-file, not system-wide.
The way in which dirty file data is flushed is well understood by
Apple, and the MBU has good communication into the organisation.
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden