[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: Jeff Moyer <jmoyer redhat com>
- To: Andrea Arcangeli <aarcange redhat com>
- Cc: 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: Mon, 23 Jan 2012 14:19:33 -0500
Andrea Arcangeli <aarcange redhat com> writes:
> On Mon, Jan 23, 2012 at 01:28:08PM -0500, Jeff Moyer wrote:
>> Are you speaking from experience? If so, what workloads were negatively
>> affected by merging, and how did you measure that?
>
> Any workload where two processes compete for accessing the same disk
> and one process writes big requests (usually async writes), the other
> small (usually sync reads). The one with the small 4k requests
> (usually reads) gets some artificial latency if the big requests are
> 512k. Vivek did a recent measurement to verify the issue is still
> there, and it's basically an hardware issue. Software can't do much
> other than possibly reducing the max request size when we notice such
> an I/O pattern coming in cfq. I did old measurements that's how I knew
> it, but they were so ancient they're worthless by now, this is why
> Vivek had to repeat it to verify before we could assume it still
> existed on recent hardware.
>
> These days with cgroups it may be a bit more relevant as max write
> bandwidth may be secondary to latency/QoS.
Thanks, Vivek was able to point me at the old thread:
http://www.spinics.net/lists/linux-fsdevel/msg44191.html
Cheers,
Jeff
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]