- Subject: Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
- From: "Loke, Chetan" <Chetan.Loke@xxxxxxxxxxxx>
- Date: Thu, 26 Jan 2012 11:17:05 -0500
- Cc: Andreas Dilger <adilger@xxxxxxxxx>, Andrea Arcangeli <aarcange@xxxxxxxxxx>, Jan Kara <jack@xxxxxxx>, linux-scsi@xxxxxxxxxxxxxxx, Mike Snitzer <snitzer@xxxxxxxxxx>, Jeff Moyer <jmoyer@xxxxxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, linux-mm@xxxxxxxxx, dm-devel@xxxxxxxxxx, Wu Fengguang <fengguang.wu@xxxxxxxxx>, Boaz Harrosh <bharrosh@xxxxxxxxxxx>, linux-fsdevel@xxxxxxxxxxxxxxx, lsf-pc@xxxxxxxxxxxxxxxxxxxxxxxxxx, Steven Whitehouse <swhiteho@xxxxxxxxxx>, Chris Mason <chris.mason@xxxxxxxxxx>
- In-reply-to: <firstname.lastname@example.org>
- References: <20120124151504.GQ4387@shiny> <20120124165631.GA8941@infradead.org> <186EA560-1720-4975-AC2F-8C72C4A777A9@dilger.ca> <email@example.com> <20120124184054.GA23227@infradead.org> <20120124190732.GH4387@shiny> <firstname.lastname@example.org> <20120124200932.GB20650@quack.suse.cz> <email@example.com> <20120124203936.GC20650@quack.suse.cz> <20120125032932.GA7150@localhost> <F6F2DEB8-F096-4A3B-89E3-3A132033BC76@dilger.ca> <1327502034.2720.23.camel@menhir> <D3F292ADF945FB49B35E96C94C2061B915A638A6@nsmail.netscout.com> <1327509623.2720.52.camel@menhir> <firstname.lastname@example.org> <D3F292ADF945FB49B35E96C94C2061B915A63A30@nsmail.netscout.com> <email@example.com>
- Reply-to: device-mapper development <dm-devel@xxxxxxxxxx>
- Thread-index: AczbkHMCBlxYUAgTRtqZ6sB9rMwNWAAs83TA
- Thread-topic: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
> > 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.
dm-devel mailing list