[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [dm-devel] [Lsf-pc] [LSF/MM TOPIC] a few storage topics
- From: Chris Mason <chris mason oracle com>
- To: Jeff Moyer <jmoyer redhat com>
- Cc: Andrea Arcangeli <aarcange redhat com>, Jan Kara <jack suse cz>, Mike Snitzer <snitzer redhat com>, linux-scsi vger kernel org, dm-devel redhat com, Boaz Harrosh <bharrosh panasas com>, linux-fsdevel vger kernel org, lsf-pc lists linux-foundation org
- Subject: Re: [dm-devel] [Lsf-pc] [LSF/MM TOPIC] a few storage topics
- Date: Tue, 24 Jan 2012 10:15:04 -0500
On Mon, Jan 23, 2012 at 01:28:08PM -0500, Jeff Moyer wrote:
> Andrea Arcangeli <aarcange redhat com> writes:
>
> > On Mon, Jan 23, 2012 at 05:18:57PM +0100, Jan Kara wrote:
> >> requst granularity. Sure, big requests will take longer to complete but
> >> maximum request size is relatively low (512k by default) so writing maximum
> >> sized request isn't that much slower than writing 4k. So it works OK in
> >> practice.
> >
> > Totally unrelated to the writeback, but the merged big 512k requests
> > actually adds up some measurable I/O scheduler latencies and they in
> > turn slightly diminish the fairness that cfq could provide with
> > smaller max request size. Probably even more measurable with SSDs (but
> > then SSDs are even faster).
>
> Are you speaking from experience? If so, what workloads were negatively
> affected by merging, and how did you measure that?
https://lkml.org/lkml/2011/12/13/326
This patch is another example, although for a slight different reason.
I really have no idea yet what the right answer is in a generic sense,
but you don't need a 512K request to see higher latencies from merging.
-chris
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]