From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Eric Wong <normalperson@yhbt.net>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fadvise: perform WILLNEED readahead in a workqueue
Date: Sun, 16 Dec 2012 16:48:59 +0800 [thread overview]
Message-ID: <20121216084859.GA5600@gmail.com> (raw)
In-Reply-To: <20121216041549.GK9806@dastard>
On Sun, Dec 16, 2012 at 03:15:49PM +1100, Dave Chinner wrote:
> On Sun, Dec 16, 2012 at 03:35:49AM +0000, Eric Wong wrote:
> > Dave Chinner <david@fromorbit.com> wrote:
> > > On Sun, Dec 16, 2012 at 12:25:49AM +0000, Eric Wong wrote:
> > > > Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > > > > On Sat, 15 Dec 2012 00:54:48 +0000
> > > > > Eric Wong <normalperson@yhbt.net> wrote:
> > > > >
> > > > > > Applications streaming large files may want to reduce disk spinups and
> > > > > > I/O latency by performing large amounts of readahead up front
>
> > This could also be a use case for an audio/video player.
>
> Sure, but this can all be handled by a userspace application. If you
> want to avoid/batch IO to enable longer spindown times, then you
> have to load the file into RAM somewhere, and you don't need special
> kernel support for that.
>
> > So no, there's no difference that matters between the approaches.
> > But I think doing this in the kernel is easier for userspace users.
>
> The kernel provides mechanisms for applications to use. You have not
> mentioned anything new that requires a new kernel mechanism to
> acheive - you just need to have the knowledge to put the pieces
> together properly. People have been solving this same problem for
> the last 20 years without needing to tweak fadvise(). Or even having
> an fadvise() syscall...
>
> Nothing about low latency IO or streaming IO is simple or easy, and
> changing how readahead works doesn't change that fact. All it does
> is change the behaviour of every other application that uses
> fadvise() to minimise IO latency....
Hi Dave,
I am wondering this patch might be a good idea to reduce the latency of
fadvise() syscall itself. I do a really simple test in my desktop to
measure the latency of fadvise syscall. Before applying this patch,
fadvise syscall takes 32 microseconds. After applying the patch, it
only takes 4 microseconds. (I was surprised that it takes a very long
time!)
Actually we observe a latency after using fadvise. But I don't find a
proper time to look at this problem. So I guess this patch might be
useful to reduce latency.
Regards,
- Zheng
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Eric Wong <normalperson@yhbt.net>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fadvise: perform WILLNEED readahead in a workqueue
Date: Sun, 16 Dec 2012 16:48:59 +0800 [thread overview]
Message-ID: <20121216084859.GA5600@gmail.com> (raw)
In-Reply-To: <20121216041549.GK9806@dastard>
On Sun, Dec 16, 2012 at 03:15:49PM +1100, Dave Chinner wrote:
> On Sun, Dec 16, 2012 at 03:35:49AM +0000, Eric Wong wrote:
> > Dave Chinner <david@fromorbit.com> wrote:
> > > On Sun, Dec 16, 2012 at 12:25:49AM +0000, Eric Wong wrote:
> > > > Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > > > > On Sat, 15 Dec 2012 00:54:48 +0000
> > > > > Eric Wong <normalperson@yhbt.net> wrote:
> > > > >
> > > > > > Applications streaming large files may want to reduce disk spinups and
> > > > > > I/O latency by performing large amounts of readahead up front
>
> > This could also be a use case for an audio/video player.
>
> Sure, but this can all be handled by a userspace application. If you
> want to avoid/batch IO to enable longer spindown times, then you
> have to load the file into RAM somewhere, and you don't need special
> kernel support for that.
>
> > So no, there's no difference that matters between the approaches.
> > But I think doing this in the kernel is easier for userspace users.
>
> The kernel provides mechanisms for applications to use. You have not
> mentioned anything new that requires a new kernel mechanism to
> acheive - you just need to have the knowledge to put the pieces
> together properly. People have been solving this same problem for
> the last 20 years without needing to tweak fadvise(). Or even having
> an fadvise() syscall...
>
> Nothing about low latency IO or streaming IO is simple or easy, and
> changing how readahead works doesn't change that fact. All it does
> is change the behaviour of every other application that uses
> fadvise() to minimise IO latency....
Hi Dave,
I am wondering this patch might be a good idea to reduce the latency of
fadvise() syscall itself. I do a really simple test in my desktop to
measure the latency of fadvise syscall. Before applying this patch,
fadvise syscall takes 32 microseconds. After applying the patch, it
only takes 4 microseconds. (I was surprised that it takes a very long
time!)
Actually we observe a latency after using fadvise. But I don't find a
proper time to look at this problem. So I guess this patch might be
useful to reduce latency.
Regards,
- Zheng
next prev parent reply other threads:[~2012-12-16 8:35 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-15 0:54 [PATCH] fadvise: perform WILLNEED readahead in a workqueue Eric Wong
2012-12-15 0:54 ` Eric Wong
2012-12-15 22:34 ` Alan Cox
2012-12-15 22:34 ` Alan Cox
2012-12-16 0:25 ` Eric Wong
2012-12-16 0:25 ` Eric Wong
2012-12-16 3:03 ` Dave Chinner
2012-12-16 3:03 ` Dave Chinner
2012-12-16 3:35 ` Eric Wong
2012-12-16 3:35 ` Eric Wong
2012-12-16 4:15 ` Dave Chinner
2012-12-16 4:15 ` Dave Chinner
2012-12-16 5:23 ` Eric Wong
2012-12-16 5:23 ` Eric Wong
2012-12-16 21:31 ` Dave Chinner
2012-12-16 21:31 ` Dave Chinner
2012-12-16 8:48 ` Zheng Liu [this message]
2012-12-16 8:48 ` Zheng Liu
2012-12-16 2:45 ` Dave Chinner
2012-12-16 2:45 ` Dave Chinner
2012-12-16 3:04 ` Eric Wong
2012-12-16 3:04 ` Eric Wong
2012-12-16 3:09 ` Eric Wong
2012-12-16 3:09 ` Eric Wong
2012-12-16 3:36 ` Dave Chinner
2012-12-16 3:36 ` Dave Chinner
2012-12-16 3:59 ` Eric Wong
2012-12-16 3:59 ` Eric Wong
2012-12-16 4:26 ` Dave Chinner
2012-12-16 4:26 ` Dave Chinner
2012-12-16 5:17 ` Eric Wong
2012-12-16 5:17 ` Eric Wong
2013-02-22 16:45 ` Phillip Susi
2013-02-22 16:45 ` Phillip Susi
2013-02-22 21:13 ` Eric Wong
2013-02-22 21:13 ` Eric Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121216084859.GA5600@gmail.com \
--to=gnehzuil.liu@gmail.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=david@fromorbit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=normalperson@yhbt.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.