linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Eric Wong <normalperson@yhbt.net>
Cc: 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 14:03:02 +1100	[thread overview]
Message-ID: <20121216030302.GI9806@dastard> (raw)
In-Reply-To: <20121216002549.GA19402@dcvr.yhbt.net>

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
> > 
> > How does it compare benchmark wise with a user thread or using the
> > readahead() call ?
> 
> Very well.
> 
> My main concern is for the speed of the initial pread()/read() call
> after open().
> 
> Setting EARLY_EXIT means my test program _exit()s immediately after the
> first pread().  In my test program (below), I wait for the background
> thread to become ready before open() so I would not take overhead from
> pthread_create() into account.
> 
> RA=1 uses a pthread + readahead()
> Not setting RA uses fadvise (with my patch)

And if you don't use fadvise/readahead at all?

> # readahead + pthread.
> $ EARLY_EXIT=1 RA=1 time  ./first_read 1G
> 0.00user 0.05system 0:01.37elapsed 3%CPU (0avgtext+0avgdata 600maxresident)k
> 0inputs+0outputs (1major+187minor)pagefaults 0swaps
> 
> # patched fadvise
> $ EARLY_EXIT=1 time ./first_read 1G
> 0.00user 0.00system 0:00.01elapsed 0%CPU (0avgtext+0avgdata 564maxresident)k
> 0inputs+0outputs (1major+178minor)pagefaults 0swaps

You're not timing how long the first pread() takes at all. You're
timing the entire set of operations, including cloning a thread and
for the readahead(2) call and messages to be passed back and forth
through the eventfd interface to read the entire file.

Why even bother with another thread for readahead()? It implements
*exactly* the same operation as fadvise(WILL_NEED) (ie.
force_page_cache_readahead), so should perform identically when
called in exactly the same manner...

But again, you are interesting in the latency of the first read of
16k from the file, but you are asking to readahead 1GB of data.
Perhaps your shoul dbe asking for readahead of something more
appropriate to what you care about - the first read....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

  reply	other threads:[~2012-12-16  3:03 UTC|newest]

Thread overview: 18+ 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 22:34 ` Alan Cox
2012-12-16  0:25   ` Eric Wong
2012-12-16  3:03     ` Dave Chinner [this message]
2012-12-16  3:35       ` Eric Wong
2012-12-16  4:15         ` Dave Chinner
2012-12-16  5:23           ` Eric Wong
2012-12-16 21:31             ` Dave Chinner
2012-12-16  8:48           ` Zheng Liu
2012-12-16  2:45 ` Dave Chinner
2012-12-16  3:04   ` Eric Wong
2012-12-16  3:09     ` Eric Wong
2012-12-16  3:36     ` Dave Chinner
2012-12-16  3:59       ` Eric Wong
2012-12-16  4:26         ` Dave Chinner
2012-12-16  5:17           ` Eric Wong
2013-02-22 16:45   ` Phillip Susi
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=20121216030302.GI9806@dastard \
    --to=david@fromorbit.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).