Phillip Susi wrote:
> > On Sat, Dec 15, 2012 at 12:54:48AM +, Eric Wong wrote:
> >> "strace -T" timing on an uncached, one gigabyte file:
> >>
> >> Before: fadvise64(3, 0, 0, POSIX_FADV_WILLNEED) = 0 <2.484832>
> >> After: fadvise64(3, 0, 0, POSIX_FADV_WILLNEED) = 0 <0.61>
>
> It should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/15/2012 9:45 PM, Dave Chinner wrote:
> On Sat, Dec 15, 2012 at 12:54:48AM +, Eric Wong wrote:
>> Applications streaming large files may want to reduce disk
>> spinups and I/O latency by performing large amounts of readahead
>> up front. Appli
On Sun, Dec 16, 2012 at 05:23:02AM +, Eric Wong wrote:
> Dave Chinner wrote:
> > On Sun, Dec 16, 2012 at 03:35:49AM +, Eric Wong wrote:
> > > Dave Chinner wrote:
> > > > On Sun, Dec 16, 2012 at 12:25:49AM +, Eric Wong wrote:
> > > > > Alan Cox wrote:
> > > > > > On Sat, 15 Dec 2012 0
On Sun, Dec 16, 2012 at 03:15:49PM +1100, Dave Chinner wrote:
> On Sun, Dec 16, 2012 at 03:35:49AM +, Eric Wong wrote:
> > Dave Chinner wrote:
> > > On Sun, Dec 16, 2012 at 12:25:49AM +, Eric Wong wrote:
> > > > Alan Cox wrote:
> > > > > On Sat, 15 Dec 2012 00:54:48 +
> > > > > Eric W
Dave Chinner wrote:
> On Sun, Dec 16, 2012 at 03:35:49AM +, Eric Wong wrote:
> > Dave Chinner wrote:
> > > On Sun, Dec 16, 2012 at 12:25:49AM +, Eric Wong wrote:
> > > > Alan Cox wrote:
> > > > > On Sat, 15 Dec 2012 00:54:48 +
> > > > > Eric Wong wrote:
> > > > >
> > > > > > Applic
Dave Chinner wrote:
> On Sun, Dec 16, 2012 at 03:59:53AM +, Eric Wong wrote:
> > I want the first read() to happen sooner than it would under current
> > fadvise.
>
> You're not listening. You do not need the kernel to be modified to
> avoid the latency of issuing 1GB of readahead on a file
On Sun, Dec 16, 2012 at 03:59:53AM +, Eric Wong wrote:
> Dave Chinner wrote:
> > On Sun, Dec 16, 2012 at 03:04:42AM +, Eric Wong wrote:
> > > Dave Chinner wrote:
> > > > On Sat, Dec 15, 2012 at 12:54:48AM +, Eric Wong wrote:
> > > > >
> > > > > Before: fadvise64(3, 0, 0, POSIX_FADV_
On Sun, Dec 16, 2012 at 03:35:49AM +, Eric Wong wrote:
> Dave Chinner wrote:
> > On Sun, Dec 16, 2012 at 12:25:49AM +, Eric Wong wrote:
> > > Alan Cox wrote:
> > > > On Sat, 15 Dec 2012 00:54:48 +
> > > > Eric Wong wrote:
> > > >
> > > > > Applications streaming large files may want
Dave Chinner wrote:
> On Sun, Dec 16, 2012 at 03:04:42AM +, Eric Wong wrote:
> > Dave Chinner wrote:
> > > On Sat, Dec 15, 2012 at 12:54:48AM +, Eric Wong wrote:
> > > >
> > > > Before: fadvise64(3, 0, 0, POSIX_FADV_WILLNEED) = 0 <2.484832>
> > > > After: fadvise64(3, 0, 0, POSIX_FADV
On Sun, Dec 16, 2012 at 03:04:42AM +, Eric Wong wrote:
> Dave Chinner wrote:
> > On Sat, Dec 15, 2012 at 12:54:48AM +, Eric Wong wrote:
> > > Applications streaming large files may want to reduce disk spinups and
> > > I/O latency by performing large amounts of readahead up front.
> > > Ap
Dave Chinner wrote:
> On Sun, Dec 16, 2012 at 12:25:49AM +, Eric Wong wrote:
> > Alan Cox wrote:
> > > On Sat, 15 Dec 2012 00:54:48 +
> > > Eric Wong wrote:
> > >
> > > > Applications streaming large files may want to reduce disk spinups and
> > > > I/O latency by performing large amoun
Eric Wong wrote:
> Perhaps squashing something like the following will work?
Last hunk should've had a return before skip_ra:
--- a/mm/readahead.c
+++ b/mm/readahead.c
@@ -264,6 +266,10 @@ void wq_page_cache_readahead(struct address_space
*mapping, struct file *filp,
req->nr_to_read = n
Dave Chinner wrote:
> On Sat, Dec 15, 2012 at 12:54:48AM +, Eric Wong wrote:
> > Applications streaming large files may want to reduce disk spinups and
> > I/O latency by performing large amounts of readahead up front.
> > Applications also tend to read files soon after opening them, so waitin
On Sun, Dec 16, 2012 at 12:25:49AM +, Eric Wong wrote:
> Alan Cox wrote:
> > On Sat, 15 Dec 2012 00:54:48 +
> > Eric Wong wrote:
> >
> > > Applications streaming large files may want to reduce disk spinups and
> > > I/O latency by performing large amounts of readahead up front
> >
> > H
On Sat, Dec 15, 2012 at 12:54:48AM +, Eric Wong wrote:
> Applications streaming large files may want to reduce disk spinups and
> I/O latency by performing large amounts of readahead up front.
> Applications also tend to read files soon after opening them, so waiting
> on a slow fadvise may cau
Alan Cox wrote:
> On Sat, 15 Dec 2012 00:54:48 +
> Eric Wong wrote:
>
> > Applications streaming large files may want to reduce disk spinups and
> > I/O latency by performing large amounts of readahead up front
>
> How does it compare benchmark wise with a user thread or using the
> readahe
On Sat, 15 Dec 2012 00:54:48 +
Eric Wong wrote:
> Applications streaming large files may want to reduce disk spinups and
> I/O latency by performing large amounts of readahead up front
How does it compare benchmark wise with a user thread or using the
readahead() call ?
--
To unsubscribe fr
Applications streaming large files may want to reduce disk spinups and
I/O latency by performing large amounts of readahead up front.
Applications also tend to read files soon after opening them, so waiting
on a slow fadvise may cause unpleasant latency when the application
starts reading the file.
18 matches
Mail list logo