This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: [PATCH 7/9] blkio-cgroup-v9: Page tracking hooks

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.

> > 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 

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 
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 


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>