WARNING - OLD ARCHIVES

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

xen-devel

[Top] [All Lists]

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

To: kamezawa.hiroyu@xxxxxxxxxxxxxx
Subject: Re: [Xen-devel] Re: [PATCH 7/9] blkio-cgroup-v9: Page tracking hooks
From: Ryo Tsuruta <ryov@xxxxxxxxxxxxx>
Date: 2009年7月24日 17:48:53 +0900 (JST)
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, containers@xxxxxxxxxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx, dm-devel@xxxxxxxxxx, agk@xxxxxxxxxx
Delivery-date: 2009年7月24日 01:49:27 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20090724151923.986dd932.kamezawa.hiroyu@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <5971c26b399a97f51dd10ea497617733.squirrel@xxxxxxxxxxxxxxxxxxxxxxxxx> <20090724.144416.71112906.ryov@xxxxxxxxxxxxx> <20090724151923.986dd932.kamezawa.hiroyu@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:
> On 2009年7月24日 14:44:16 +0900 (JST)
> Ryo Tsuruta <ryov@xxxxxxxxxxxxx> wrote:
> good solution to resolve such problem.
> > 
> > > My point is "don't allow anyone to use bandwidth of others."
> > > Considering job isolation, a thread who requests swap-out should be charg=
> > > ed
> > > against bandwidth.
> > 
> > From another perspective, the swap-out is caused since the buggy
> > process uses a large amount of memory, so it can be considered as 
> > the bandwidth of logging process is used due to the buggy process.
> > 
> > Please consider the following case. If a thread who requests swap-out
> > is charged, the thread is charged other threads' I/O.
> > 
> > (1) -------- (2)
> > Process A | | Process B
> > mmaps a large area in --> | memory | <-- tries to allocate a page.
> > the memory and writes | |
> > data to there. -------- (3)
> > | To get a free page,
> > | the data written by Proc.A
> > | is written out to the disk.
> > V The I/O is done by using
> > --------- Proc.B's bandwidth.
> > | disk | 
> > ---------
> > 
> > Thus I think that page owners should be charged against bandwidth.
> > 
> Ok, no good way. yours is wrong, mine is wrong, too.
> plz find 3rd way, reasonable.
>
> Below is brief thinking.
>
> "Why process A should be charged to I/O when it just maps anon memory ?"
> I can't answer this.
>
> Even in yorr case, Process B requests memory and get penalty. It's
> very natural, I think.
>
> In usual case, 
> - if process A maps ANON, there will be no I/O.
> - if process A maps FILE, it will be charged to process A.
> ok ?
>
> Under memory pressure,
> - if process A maps ANON, swap I/O should be charged to process B.
> - if process A maps FILE, I/O should be charged to process A.
> maybe. 
I think that even process A maps ANON, it should be charged to process A
because the memory pressure is caused by process A. It seems natual
for me that a process which consumes more resources is more likely to
get penalty.
> Anyway, there will be ineraction with dirty_ratio of memcg (not implemeted 
> yet)
> and _Owner should be charged_ issue will be handled in this dirty_ratio layer.
> More consideration is necessary, I think.
I'll keep thinking how it should be done.
Thanks,
Ryo Tsuruta
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>
Previous by Date: Re: Re[8]: [Xen-devel] Unable to Configure Xen Dom 0 in Jeremy's PVOPS Kernel , Teo En Ming
Next by Date: Re: [Xen-devel] Re: Xen 3.4 multi-function pass-through tree, isn't working... , Simon Horman
Previous by Thread: Re: [Xen-devel] Re: [PATCH 7/9] blkio-cgroup-v9: Page tracking hooks , KAMEZAWA Hiroyuki
Next by Thread: [Xen-devel] Re: [PATCH 5/9] blkio-cgroup-v9: The body of blkio-cgroup , KAMEZAWA Hiroyuki
Indexes: [Date] [Thread] [Top] [All Lists]

Copyright ©, Citrix Systems Inc. All rights reserved. Legal and Privacy
Citrix This site is hosted by Citrix

AltStyle によって変換されたページ (->オリジナル) /