KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:
> On Wed, 22 Jul 2009 18:40:55 +0900 (JST)
> Ryo Tsuruta <ryov@xxxxxxxxxxxxx> wrote:
>
> > KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:
> > > On Tue, 21 Jul 2009 23:23:16 +0900 (JST)
> > > Ryo Tsuruta <ryov@xxxxxxxxxxxxx> wrote:
> > >
> > > > This patch contains several hooks that let the blkio-cgroup framework
> > > > to know
> > > > which blkio-cgroup is the owner of a page before starting I/O against
> > > > the page.
> > >
> > > > @@ -464,6 +465,7 @@ int add_to_page_cache_locked(struct page
> > > > gfp_mask & GFP_RECLAIM_MASK);
> > > > if (error)
> > > > goto out;
> > > > + blkio_cgroup_set_owner(page, current->mm);
> > > >
> > >
> > > This part is doubtful...Is this necessary ?
> > > I recommend you that the caller should attach owner by itself.
> >
> > I think that it is reasonable to add the hook right here rather than
> > to add many hooks to a variety of places.
> >
> Why ? at writing, it's will be overwriten soon, IIUC. Then, this information
> is misleading. plz add a hook like this when it means something. In this case,
> read/write callers.
> IMO, you just increase patch's readbility but decrease easiness of maintaince.
Even though the owner is overwritten soon at writing, I'm not sure why
inserting the hook here causes the misleading. I think that it is easy
to understand when and where the owner is set by blkio-cgroup, and it
does not decrease maintainability, rather than put many hooks to each
caller.
> > > IMHO, later io for swap-out is caused by the caller of swapout, not page's
> > > owner. plz charge to them or,
> > > - add special BLOCK CGROUP ID for the kernel's swap out.
> >
> > I think that it is not too bad to charge the owner of a page for
> > swap-out. From another perspective, it can be considered that swap-out
> > is caused by a process which uses a large amount of memory.
> >
> No. swap-out is caused by a thread who requests memory even while memory is
> in short. IMHO, I/O by memory reqraim should work in priority of memory
> requester.
>
> Consider following situation.
>
> - A process "A" has big memory. When several threads requests memory, all
> of them are caught by a blockio cgroup of "A".
> - A process "B" has read big file caches. When several threads requests
> memory,
> all of them are caught by a blockio cgroup of "B".
>
> If "A" and "B" 's threshold is small, you'll see big slow down.
> But it's not _planned_ behavior in many cases.
>
> If you charges agaisnt memory owner, the admin has to set _big_ priority of
> I/O
> controller to "A" and "B" if it uses much memory. I think the admin can't
> design
> his system. It's nonsense to say "plz set I/O limit propotional to memory
> usage of
> your apps even if it never do I/O in usual."
>
> If this blockio cgroup is introduced, people will see *unexpected* very
> terrible slow down and the user will see heartbeat warnings/failover by
> cluster
> management software. Please do I/O at the priority of memory reclaiming
> requester.
dm-ioband gives high priority to I/O for swap-out by checking whether
PG_swapcache flag is set on the I/O page, regardless of the assigned
I/O bandwidth, and the bandwidth consumed for swap-out is charged to
the owner of the pages as a debt.
How about this approach?
Thanks,
Ryo Tsuruta
>
>
> Thanks,
> -Kame
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home