Re: open(O_DIRECT) on a tmpfs?

[Denis Vlasenko <vda.linux@googlemail.com>]

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!

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".

DB people from certain well-known commercial DB have zero coding
taste. No wonder their binaries are nearly 100 MB (!!!) in size...

In all fairness, O_DIRECT's direct-DMA makes is easier to implement
"do-not-cache-me" than to do it for generic read()/write()
(just because O_DIRECT is (was?) using different code path,
not integrated into VM cache machinery that much).

But _conceptually_ "direct DMAing" and "do-not-cache-me"
are orthogonal, right?

That's why we also have bona fide fadvise and madvise
with FADV_DONTNEED/MADV_DONTNEED:

http://www.die.net/doc/linux/man/man2/fadvise.2.html
http://www.die.net/doc/linux/man/man2/madvise.2.html

_This_ is the proper way to say "do not cache me".

I think tmpfs should just ignore O_DIRECT bit.
That won't require much coding.
--
vda