Re: open(O_DIRECT) on a tmpfs?

[Nick Piggin <nickpiggin@yahoo.com.au>]

Denis Vlasenko wrote:
> On Thursday 04 January 2007 17:19, Bill Davidsen wrote:
> 
>>Hugh Dickins wrote:
>>In many cases the use of O_DIRECT is purely to avoid impact on cache 
>>used by other applications. An application which writes a large quantity 
>>of data will have less impact on other applications by using O_DIRECT, 
>>assuming that the data will not be read from cache due to application 
>>pattern or the data being much larger than physical memory.
> 
> 
> But O_DIRECT is _not_ about cache. At least I think it was not about
> cache initially, it was more about DMAing data directly from/to
> application address space to/from disks, saving memcpy's and double
> allocations. Why do you think it has that special alignment requirements?
> Are they cache related? Not at all!

I don't know whether that is the case. The two issues are related -- the
IO is be done zero-copy because there is no cache involved, and due to
there being no cache, there are alignment restrictions.

I think IRIX might have implemented O_DIRECT first, and although the
semantics are a bit vague, I think it has always been to do zero copy
IO _and_ to bypass cache (ie. no splice-like tricks).

> After that people started adding unrelated semantics on it -
> "oh, we use O_DIRECT in our database code and it pushes EVERYTHING
> else out of cache. This is bad. Let's overload O_DIRECT to also mean
> 'do not pollute the cache'. Here's the patch".

It is because they already do their own caching, so going through
another, dumber, cache of same or less size (the pagecache) is useless.
fadvise does not change that.

That said, tmpfs's page are not really a cache (except when they are
swapcache, but let's not complicate things). So O_DIRECT on tmpfs
may not exactly be wrong.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com