Message-ID: <3C945A5A.9673053F@zip.com.au>
Date: Sun, 17 Mar 2002 00:56:58 -0800
From: Andrew Morton <akpm@zip.com.au>
MIME-Version: 1.0
To: Jeff Garzik <jgarzik@mandrakesoft.com>
CC: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: fadvise syscall?
In-Reply-To: <3C945635.4050101@mandrakesoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org

Jeff Garzik wrote:
> 
> Has anyone ever done an madvise(2)-type syscall for file descriptors?
> (or does the capability exist and I'm missing it?)

Well, question is: is madvise() any use? :)

> I was thinking, in playing around with stuff like cp(1) I've found that
> standard read(2) and write(2) of a 4-8K buffer is the fastest solution
> overall, in addition to providing the useful side effect of better error
> reporting, such as ENOSPC report.  Better error reporting than the
> alternative I see anyway, mmap(2).

4k to 8k is best on x86 at least.  And if you're actually going to *use*
each byte in the file, the zero-copy characteristics of mmap aren't
worth much at all.
 
> So... we have madvise, why not fadvise?  I would love the capability for
> applications to provide hints to the OS like madvise, but for file
> descriptors...

The one hint which I can think of which would be beneficial would
be an equivalent to MADV_SEQUENTIAL.  Something which says "this
is a big streaming read/write - don't go and evict other stuff because
of it".  O_STREAMING perhaps.  Or working dropbehind heuristics,
although I suspect that explicit controls will always do better.

For MADV_RANDOM, readahead window scaling should get that right.

What else were you thinking of?

-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/