- Subject: Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
- From: "Loke, Chetan" <Chetan.Loke@xxxxxxxxxxxx>
- Date: Wed, 25 Jan 2012 13:37:16 -0500
- Cc: Andreas Dilger <adilger@xxxxxxxxx>, Andrea Arcangeli <aarcange@xxxxxxxxxx>, Jan Kara <jack@xxxxxxx>, Mike Snitzer <snitzer@xxxxxxxxxx>, linux-scsi@xxxxxxxxxxxxxxx, dm-devel@xxxxxxxxxx, Christoph Hellwig <hch@xxxxxxxxxxxxx>, linux-mm@xxxxxxxxx, Jeff Moyer <jmoyer@xxxxxxxxxx>, Wu Fengguang <fengguang.wu@xxxxxxxxx>, Boaz Harrosh <bharrosh@xxxxxxxxxxx>, linux-fsdevel@xxxxxxxxxxxxxxx, lsf-pc@xxxxxxxxxxxxxxxxxxxxxxxxxx, Chris Mason <chris.mason@xxxxxxxxxx>
- In-reply-to: <D3F292ADF945FB49B35E96C94C2061B915A63A30@nsmail.netscout.com>
- References: <20120124151504.GQ4387@shiny> <20120124165631.GA8941@infradead.org> <186EA560-1720-4975-AC2F-8C72C4A777A9@dilger.ca> <firstname.lastname@example.org> <20120124184054.GA23227@infradead.org> <20120124190732.GH4387@shiny> <email@example.com> <20120124200932.GB20650@quack.suse.cz> <firstname.lastname@example.org> <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> <email@example.com> <D3F292ADF945FB49B35E96C94C2061B915A63A30@nsmail.netscout.com>
- Reply-to: device-mapper development <dm-devel@xxxxxxxxxx>
- Thread-index: Aczbh0Xk4k97jyYRRmmnsbVRL8rSBwABPuiAAADcGjA=
- Thread-topic: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
> > So there are two separate problems mentioned here. The first is to
> > ensure that readahead (RA) pages are treated as more disposable than
> > accessed pages under memory pressure and then to derive a statistic for
> > futile RA (those pages that were read in but never accessed).
> > The first sounds really like its an LRU thing rather than adding yet
> > another page flag. We need a position in the LRU list for never
> > accessed ... that way they're first to be evicted as memory pressure
> > rises.
> > The second is you can derive this futile readahead statistic from the
> > LRU position of unaccessed pages ... you could keep this globally.
> > Now the problem: if you trash all unaccessed RA pages first, you end up
> > with the situation of say playing a movie under moderate memory
> > pressure that we do RA, then trash the RA page then have to re-read to display
> > to the user resulting in an undesirable uptick in read I/O.
James - now that I'm thinking about it. I think the movie should be fine because when we calculate the read-hit from RA'd pages, the movie RA blocks will get a good hit-ratio and hence it's RA'd blocks won't be touched. But then we might need to track the hit-ratio at the RA-block(?) level.
dm-devel mailing list