From: "Loke, Chetan" <Chetan.Loke@netscout.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Steven Whitehouse <swhiteho@redhat.com>,
Andreas Dilger <adilger@dilger.ca>,
Andrea Arcangeli <aarcange@redhat.com>, Jan Kara <jack@suse.cz>,
Mike Snitzer <snitzer@redhat.com>,
linux-scsi@vger.kernel.org, neilb@suse.de, dm-devel@redhat.com,
Christoph Hellwig <hch@infradead.org>,
linux-mm@kvack.org, Jeff Moyer <jmoyer@redhat.com>,
Wu Fengguang <fengguang.wu@gmail.com>,
Boaz Harrosh <bharrosh@panasas.com>,
linux-fsdevel@vger.kernel.org, lsf-pc@lists.linux-foundation.org,
Chris Mason <chris.mason@oracle.com>,
"Darrick J.Wong" <djwong@us.ibm.com>
Subject: RE: [Lsf-pc] [dm-devel] [LSF/MM TOPIC] a few storage topics
Date: Thu, 26 Jan 2012 11:17:05 -0500 [thread overview]
Message-ID: <D3F292ADF945FB49B35E96C94C2061B915A640A5@nsmail.netscout.com> (raw)
In-Reply-To: <1327516668.7168.7.camel@dabdike.int.hansenpartnership.com>
> > Well, the movie example is one case where evicting unaccessed page may not be the right thing to do. But what about a workload that perform a random one-shot search?
> > The search was done and the RA'd blocks are of no use anymore. So it seems one solution would hurt another.
>
> Well not really: RA is always wrong for random reads. The whole purpose of RA is assumption of sequential access patterns.
>
James - I must agree that 'random' was not the proper choice of word here. What I meant was this -
search-app reads enough data to trick the lazy/deferred-RA logic. RA thinks, oh well, this is now a sequential pattern and will RA.
But all this search-app did was that it kept reading till it found what it was looking for. Once it was done, it went back to sleep waiting for the next query.
Now all that RA data could be of total waste if the read-hit on the RA data-set was 'zero percent'.
Some would argue that how would we(the kernel) know that the next query may not be close the earlier data-set? Well, we don't and we may not want to. That is why the application better know how to use XXX_advise calls. If they are not using it then well it's their problem. The app knows about the statistics/etc about the queries. What was used and what wasn't.
> James
Chetan Loke
next prev parent reply other threads:[~2012-01-26 16:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20120124151504.GQ4387@shiny>
[not found] ` <20120124165631.GA8941@infradead.org>
[not found] ` <186EA560-1720-4975-AC2F-8C72C4A777A9@dilger.ca>
[not found] ` <x49fwf5kmbl.fsf@segfault.boston.devel.redhat.com>
[not found] ` <20120124184054.GA23227@infradead.org>
[not found] ` <20120124190732.GH4387@shiny>
[not found] ` <x49vco0kj5l.fsf@segfault.boston.devel.redhat.com>
[not found] ` <20120124200932.GB20650@quack.suse.cz>
[not found] ` <x49pqe8kgej.fsf@segfault.boston.devel.redhat.com>
[not found] ` <20120124203936.GC20650@quack.suse.cz>
[not found] ` <20120125032932.GA7150@localhost>
[not found] ` <F6F2DEB8-F096-4A3B-89E3-3A132033BC76@dilger.ca>
[not found] ` <1327502034.2720.23.camel@menhir>
[not found] ` <D3F292ADF945FB49B35E96C94C2061B915A638A6@nsmail.netscout.com>
[not found] ` <1327509623.2720.52.camel@menhir>
2012-01-25 17:32 ` James Bottomley
2012-01-25 18:28 ` Loke, Chetan
2012-01-25 18:37 ` Loke, Chetan
2012-01-25 18:37 ` James Bottomley
2012-01-25 20:06 ` Chris Mason
2012-01-25 22:46 ` Andrea Arcangeli
2012-01-25 22:58 ` Jan Kara
2012-01-26 8:59 ` Boaz Harrosh
2012-01-26 16:40 ` Loke, Chetan
2012-01-26 17:00 ` Andreas Dilger
2012-01-26 17:16 ` Loke, Chetan
2012-02-03 12:37 ` Wu Fengguang
2012-01-26 22:38 ` Dave Chinner
2012-01-26 16:17 ` Loke, Chetan [this message]
2012-01-25 18:44 ` Boaz Harrosh
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=D3F292ADF945FB49B35E96C94C2061B915A640A5@nsmail.netscout.com \
--to=chetan.loke@netscout.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=aarcange@redhat.com \
--cc=adilger@dilger.ca \
--cc=bharrosh@panasas.com \
--cc=chris.mason@oracle.com \
--cc=djwong@us.ibm.com \
--cc=dm-devel@redhat.com \
--cc=fengguang.wu@gmail.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=jmoyer@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-scsi@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=neilb@suse.de \
--cc=snitzer@redhat.com \
--cc=swhiteho@redhat.com \
/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