[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
[dm-devel] Re: RFC: I/O bandwidth controller
- From: Fernando Luis Vázquez Cao <fernando oss ntt co jp>
- To: Hirokazu Takahashi <taka valinux co jp>
- Cc: xen-devel lists xensource com, uchida ap jp nec com, containers lists linux-foundation org, linux-kernel vger kernel org, virtualization lists linux-foundation org, dm-devel redhat com, righi andrea gmail com, agk sourceware org, dave linux vnet ibm com, ngupta google com, balbir linux vnet ibm com
- Subject: [dm-devel] Re: RFC: I/O bandwidth controller
- Date: Tue, 12 Aug 2008 05:35:51 -0000
On Fri, 2008-08-08 at 20:39 +0900, Hirokazu Takahashi wrote:
> Hi,
>
> > > Would you like to split up IO into read and write IO. We know that read can be
> > > very latency sensitive when compared to writes. Should we consider them
> > > separately in the RFC?
> > Oops, I somehow ended up leaving your first question unanswered. Sorry.
> >
> > I do not think we should consider them separately, as long as there is a
> > proper IO tracking infrastructure in place. As you mentioned, reads can
> > be very latecy sensitive, but the read case could be treated as an
> > special case IO controller/IO tracking subsystem. There certainly are
> > optimization opportunities. For example, in the synchronous I/O patch ww
> > could mark bios with the iocontext of the current task, because it will
> > happen to be originator of that IO. By effectively caching the ownership
> > information in the bio we can avoid all the accesses to struct page,
> > page_cgroup, etc, and reads would definitively benefit from that.
>
> FYI, we should also take special care of pages being reclaimed, the free
> memory of the cgroup these pages belong to may be really low.
> Dm-ioband is doing this.
Thank you for the heads-up.
- Fernando
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]