On Mon, 20 Oct 2008 21:48:58 +0900 (JST)
Ryo Tsuruta <[EMAIL PROTECTED]> wrote:
> Hi Dong-Jae,
>
> > Well, do you have any plan to upgrade bio-cgroup patches for stable
> > latest kernel?
> > but, I think it will be not easy job ^^
>
> I think the memory cgroup will have a major change sometime
On Wed, 29 Oct 2008 17:07:18 +0900 (JST)
Hirokazu Takahashi <[EMAIL PROTECTED]> wrote:
> Hi,
>
> > Hi Ryo,
> >
> > The page_cgroup seems to be stable in the latest kernel.
> > I'd like to know whether you have a plan or schedule to release
> > a new version of bio-cgroup against latest kernel.
>
On Wed, 29 Oct 2008 14:32:29 +0530
Balbir Singh <[EMAIL PROTECTED]> wrote:
> KAMEZAWA Hiroyuki wrote:
> > On Wed, 29 Oct 2008 17:07:18 +0900 (JST)
> > Hirokazu Takahashi <[EMAIL PROTECTED]> wrote:
> >
> >> Hi,
> >>
> >>> Hi Ryo,
>
On Tue, 4 Nov 2008 15:36:10 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Tue, 4 Nov 2008 16:52:48 -0600 (CST)
> Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 4 Nov 2008, Andrew Morton wrote:
> >
> > > To fix this with a memcg-based throttling, the operator would need to
> > >
On Tue, 4 Nov 2008 19:05:05 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> Generally, I worry that this is a specific fix to a specific problem
> encountered on specific machines with specific setups and specific
> workloads, and that it's just all too low-level and myopic.
>
> And now we're bac
On Wed, 5 Nov 2008 14:04:42 -0800 (PST)
David Rientjes <[EMAIL PROTECTED]> wrote:
> > So the world wouldn't end if we just didn't merge it. Those users
> > stick with their workarounds and the kernel remains simpler and
> > smaller.
> >
>
> Agreed. This patchset is admittedly from a different
On Thu, 06 Nov 2008 10:30:23 -0500
[EMAIL PROTECTED] wrote:
> +ISSUES
> +==
> +- IO controller can buffer the bios if suffcient tokens were not available
> + at the time of bio submission. Once the tokens are available, these bios
> + are dispatched to elevator/lower layers in first come firs
On Thu, 06 Nov 2008 10:30:24 -0500
[EMAIL PROTECTED] wrote:
>
> o biocgroup functionality.
> o Implemented new controller "bio"
> o Most of it picked from dm-ioband biocgroup implementation patches.
>
page_cgroup implementation is changed and most of this patch needs rework.
please see the lates
On Thu, 06 Nov 2008 10:30:25 -0500
[EMAIL PROTECTED] wrote:
>
> o Core IO controller implementation
>
> Signed-off-by: Vivek Goyal <[EMAIL PROTECTED]>
>
2 comments after a quick look.
- I don't recommend generic work queue. More stacked dependency between "work"
is not good. (I think disk
I forget to say that I like your new design in general ;)
Thanks,
-Kame
On Thu, 06 Nov 2008 10:30:23 -0500
[EMAIL PROTECTED] wrote:
>
> Signed-off-by: Vivek Goyal <[EMAIL PROTECTED]>
>
> Index: linux17/Documentation/controllers/io-controller.txt
> ==
Vivek Goyal said:
> On Fri, Nov 07, 2008 at 12:21:45PM +0900, KAMEZAWA Hiroyuki wrote:
>> On Thu, 06 Nov 2008 10:30:25 -0500
>> [EMAIL PROTECTED] wrote:
>>
>> >
>> > o Core IO controller implementation
>> >
>> > Signed-off-by: Vivek Goya
On Thu, 13 Nov 2008 12:10:19 +0900 (JST)
Ryo Tsuruta <[EMAIL PROTECTED]> wrote:
> Hi everyone,
>
> This is a new release of dm-ioband and bio-cgroup. With this release,
> the overhead of bio-cgroup is significantly reduced and the accuracy
> of block I/O tracking is much improved. These patches a
On Fri, 14 Nov 2008 11:52:41 +0800
Li Zefan <[EMAIL PROTECTED]> wrote:
> CC: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
> CC: Balbir Singh <[EMAIL PROTECTED]>
>
> Andrew Morton wrote:
> > (cc [EMAIL PROTECTED])
> >
> > On Thu, 13 Nov 2008 17:
ot based
on NR_CPUS but based on nr_cpu_ids.
From: Jan Blunck <[EMAIL PROTECTED]>
Signed-off-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
---
mm/memcontrol.c | 34 ++
1 file changed, 18 insertions(+), 16 deletions(-)
Index: mmotm-2.6.2
u_ids.
Changelog:
- fixed lack of logic in error path.
From: Jan Blunck <[EMAIL PROTECTED]>
Reviewed-by: Li Zefan <[EMAIL PROTECTED]>
Signed-off-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
---
mm/memcontrol.c | 35 ++-
1 file changed, 1
On Fri, 14 Nov 2008 13:13:29 +0530
Balbir Singh <[EMAIL PROTECTED]> wrote:
> KAMEZAWA Hiroyuki wrote:
> > How about this one ?
> > tested on x86-64 + mmotm-Nov10, works well.
> > (test on other arch is welcome.)
> >
> > -Kame
> > ==
> > As Jan
On Fri, 14 Nov 2008 13:33:49 +0530
Balbir Singh <[EMAIL PROTECTED]> wrote:
> Li Zefan wrote:
> +static int mem_cgroup_size(void)
> >>> inline this function?
> >>>
> >> necessary ?
> >>
> >
> > Not so necessary IMO. It's called when a cgroup is created and removed, that
> > is mkdir and rmdi
On Fri, 21 Nov 2008 11:59:20 +0800
Li Zefan <[EMAIL PROTECTED]> wrote:
> s/contoller/controller
>
> Signed-of-by: Li Zefan <[EMAIL PROTECTED]>
Thanks,
Acked-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
> ---
> init/Kconfig |2 +-
> 1 files changed, 1 ins
On Fri, 21 Nov 2008 16:49:43 +0800
Lai Jiangshan <[EMAIL PROTECTED]> wrote:
>
> mm_match_cgroup() calls cgroup_subsys_state().
>
> we must use rcu_read_lock() to protect cgroup_subsys_state().
>
Thanks,
Reviewed-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
> Signed
On Sat, 29 Nov 2008 12:59:27 +0530
Nikanth Karthikesan <[EMAIL PROTECTED]> wrote:
> Currently we just check for thread group leader in attach() handler but do
> nothing! Either (1) move it to can_attach handler or (2) remove the test
> itself. I am attaching patches for both below.
>
> Thanks
s.
Balbir, how do you think ?
Reviewed-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
Anyway we have to visit here, again.
> Remove the unused test for thread group leader in mem_cgroup_move_task.
>
> Signed-off-by: Nikanth Karthikesan <[EMAIL PROTECTED]>
>
> ---
>
> di
gt; Thanks
>> > Nikanth
>> >
>> Hmm, it seem that code is obsolete. thanks.
>> Balbir, how do you think ?
>>
>> Reviewed-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
>>
>> Anyway we have to visit here, again.
>
> Sorry, I did not
thank you for this work.
On Wed, 10 Dec 2008 15:36:55 -0800
[EMAIL PROTECTED] wrote:
> This patch adds a hierarchy_mutex to the cgroup_subsys object that
> protects changes to the hierarchy observed by that subsystem. It is
> taken by the cgroup subsystem (in addition to cgroup_mutex) for the
> f
On Wed, 10 Dec 2008 15:36:56 -0800
[EMAIL PROTECTED] wrote:
> This patch updates the memory controller to use its hierarchy_mutex
> rather than calling cgroup_lock() to protected against
> cgroup_mkdir()/cgroup_rmdir() from occurring in its hierarchy.
>
> Signed-off-by: Paul Menage <[EMAIL PROTEC
On Wed, 10 Dec 2008 15:36:57 -0800
[EMAIL PROTECTED] wrote:
> This patch adds css_tryget(), that obtains a counted reference on a
> CSS. It is used in situations where the caller has a "weak" reference
> to the CSS, i.e. one that does not protect the cgroup from removal via
> a reference count, b
On Wed, 10 Dec 2008 16:52:57 -0800
Paul Menage <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 10, 2008 at 4:49 PM, KAMEZAWA Hiroyuki
> <[EMAIL PROTECTED]> wrote:
> >
> >an operation like rmdir() in somewhere.
> >hierarchy_lock for A (acquire
On Wed, 10 Dec 2008 15:36:57 -0800
[EMAIL PROTECTED] wrote:
> This patch adds css_tryget(), that obtains a counted reference on a
> CSS. It is used in situations where the caller has a "weak" reference
> to the CSS, i.e. one that does not protect the cgroup from removal via
> a reference count, b
On Thu, 11 Dec 2008 12:03:07 +0530
Balbir Singh <[EMAIL PROTECTED]> wrote:
> * KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> [2008-12-11 10:05:01]:
>
> > On Wed, 10 Dec 2008 16:52:57 -0800
> > Paul Menage <[EMAIL PROTECTED]> wrote:
> >
> > >
n know css is alive or not and
get refcnt of css in very safe way.
("alive" here means "rmdir/destroy" is not called.)
This patch replaces css_get() to css_tryget(), where I cannot explain
why css_get() is safe. And removes memcg->obsolete flag.
Signed-off-by: KAMEZAWA
On Wed, 10 Dec 2008 23:28:12 -0800
Paul Menage <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 10, 2008 at 9:15 PM, KAMEZAWA Hiroyuki
> <[EMAIL PROTECTED]> wrote:
> >
> > Could you add this ?
> > ==
> > boolcss_is_removed(struct cgroup_subsys_state *css)
&g
On Thu, 11 Dec 2008 09:05:47 -0800
Paul Menage wrote:
> On Wed, Dec 10, 2008 at 10:53 PM, KAMEZAWA Hiroyuki
> wrote:
> >
> > Could you write a document to explain what kind of nest of locks are allowed
> > before merging this ?
>
> We should probably tr
On Thu, 18 Dec 2008 11:29:06 +0800
"Ian jonhson" wrote:
> Hi Balbin,
>
> I am very interested in the memory control of container,
> but I don't know where I can find the patches to push the
> functionalities and how to use the codes via some example
> or use cases.
>
Because it has much relatio
gt; Signed-off-by: Li Zefan
Oh, I love this patch. Thank you!
(about memcg part)
Acked-by: KAMEZAWA Hiroyuki
> ---
> Documentation/cgroups/cgroups.txt|5 +++--
> Documentation/cgroups/memcg_test.txt |2 +-
> Documentation/scheduler/sched-design-C
On Wed, 14 Jan 2009 11:24:18 +0800
Li Zefan wrote:
> (suppose: memcg->use_hierarchy == 0 and memcg->swappiness == 60)
>
> echo 10 > /memcg/0/swappiness |
> mem_cgroup_swappiness_write() |
> ... | echo 1 > /memcg/0/use_hierarchy
> |
On Wed, 14 Jan 2009 14:47:18 +0800
Li Zefan wrote:
> KAMEZAWA Hiroyuki wrote:
> > On Wed, 14 Jan 2009 11:24:18 +0800
> > Li Zefan wrote:
> >
> >> (suppose: memcg->use_hierarchy == 0 and memcg->swappiness == 60)
> >>
> >> echo 10 > /
On Wed, 14 Jan 2009 15:22:06 +0800
Li Zefan wrote:
> KAMEZAWA Hiroyuki wrote:
> > On Wed, 14 Jan 2009 14:47:18 +0800
> > Li Zefan wrote:
> >
> >> KAMEZAWA Hiroyuki wrote:
> >>> On Wed, 14 Jan 2009 11:24:18 +0800
> >>> Li Zefan wrote:
>
On Thu, 15 Jan 2009 18:20:45 -0800
Matthew Helsley wrote:
> On Fri, 2009-01-09 at 15:32 +0900, KAMEZAWA Hiroyuki wrote:
> > On Thu, 8 Jan 2009 22:26:46 -0800
> > Paul Menage wrote:
> >
> > > On Thu, Jan 8, 2009 at 9:32 PM, KAMEZAWA Hiroyuki
> > > wr
On Fri, 16 Jan 2009 11:45:02 +0900
KAMEZAWA Hiroyuki wrote:
> On Thu, 15 Jan 2009 18:20:45 -0800
> Matthew Helsley wrote:
> I think
> - Paul's suggestion sounds attractive. But I can't see fundamental
> differences
> from user's side between "impl
From: KAMEZAWA Hiroyuki
Now, cgrp->sibling is handled under hierarchy mutex.
error route should do so, too.
Signed-off-by: KAMEZAWA Hiroyuki
---
kernel/cgroup.c |2 ++
1 file changed, 2 insertions(+)
Index: mmotm-2.6.29-Jan14/kernel/cgrou
On Sat, 17 Jan 2009 12:26:38 -0800
Sukadev Bhattiprolu wrote:
>
> Container-init must behave like global-init to processes within the
> container and hence it must be immune to unhandled fatal signals from
> within the container (i.e SIG_DFL signals that terminate the process).
>
> But the same
On Sun, 18 Jan 2009 17:32:16 -0600
"Serge E. Hallyn" wrote:
> Quoting Daniel Lezcano (daniel.lezc...@free.fr):
> > Serge E. Hallyn wrote:
> >> Quoting Daniel Lezcano (daniel.lezc...@free.fr):
> >>
> >>> Hi,
> >>>
> >>> While trying to unshare a namespace with the clone syscall with an
> >>>
On Mon, 19 Jan 2009 17:52:36 -0800
Paul Menage wrote:
> On Thu, Jan 15, 2009 at 6:20 PM, Matthew Helsley wrote:
> >
> >My feeling is this should be a signal subsystem rather than a NOOP
> > subsystem. Then, if users want the grouping for something besides
> > signaling, it doesn't matter
On Tue, 20 Jan 2009 19:05:00 -0800
Sukadev Bhattiprolu wrote:
> KAMEZAWA Hiroyuki [kamezawa.hir...@jp.fujitsu.com] wrote:
> | On Sat, 17 Jan 2009 12:26:38 -0800
> | Sukadev Bhattiprolu wrote:
> |
> | >
> | > Container-init must behave like global-init to processes wi
On Tue, 20 Jan 2009 20:16:40 -0800
ebied...@xmission.com (Eric W. Biederman) wrote:
> KAMEZAWA Hiroyuki writes:
>
> > What makes me confused is "Container". There is no "Container" in
> > the linux kernel, just cgroup and its subsyss.
> > (Some sou
On Wed, 21 Jan 2009 12:49:50 -0800 (PST)
David Rientjes wrote:
> On Wed, 21 Jan 2009, Nikanth Karthikesan wrote:
>
> > This is a container group based approach to override the oom killer
> > selection
> > without losing all the benefits of the current oom killer heuristics and
> > oom_adj int
On Wed, 21 Jan 2009 16:38:21 +0530
Nikanth Karthikesan wrote:
> As Alan Cox suggested/wondered in this thread,
> http://lkml.org/lkml/2009/1/12/235 , this is a container group based approach
> to override the oom killer selection without losing all the benefits of the
> current oom killer heur
On Thu, 22 Jan 2009 10:43:12 +0530
Nikanth Karthikesan wrote:
> On Thursday 22 January 2009 08:58:43 KAMEZAWA Hiroyuki wrote:
> > On Wed, 21 Jan 2009 16:38:21 +0530
> >
> > Nikanth Karthikesan wrote:
> > > As Alan Cox suggested/wondered in this thread,
> >
On Mon, 02 Feb 2009 16:54:58 -0600
"Chris Friesen" wrote:
> Thadeu Lima de Souza Cascardo wrote:
>
> > Linux Documentation is not consistent and have some funny options. In
> > Documentation/cgroups/*, we have:
>
> > So, we have some more options now: /cgroups, /containers, /dev/cpuset,
> > /de
Followings are 3 stories of remount cgroup,
1. remount with devices.
# mount -t cgroup none /cgroups -ocpuacct,release_agent=xxx
# echo > /cgroups/release_agent #clear release agent by hand
# mount -t cgroup none /cgroups -oremount,cpuacct
# cat /cgroups/release_agent
=> release_agent is
Paul Menage さんは書きました:
> On Fri, Feb 20, 2009 at 2:02 AM, KAMEZAWA Hiroyuki
> wrote:
>>
>> 2. /proc/mounts information of release_agent should be updated
>> when it's overwritten directly.
>
> Yes, definitely. But shouldn't that happen already?
>
On Mon, 23 Feb 2009 10:32:46 +0800
Li Zefan wrote:
> KAMEZAWA Hiroyuki wrote:
> > Paul Menage さんは書きました:
> >> On Fri, Feb 20, 2009 at 2:02 AM, KAMEZAWA Hiroyuki
> >> wrote:
> >>> 2. /proc/mounts information of release_agent should be updated
> >
On Mon, 23 Feb 2009 10:56:04 +0800
Li Zefan wrote:
> Li Zefan wrote:
> >> 1. Documentation/cgroups/cgroup.txt says
> >>#mount -oremount,cpuset,ns /dev/cgroup
> >>But this should be
> >>#mount -tcgroup none /dev/cgroup -oremount,cpuset,ns
> >>
> >
> > I agree. Actually I noticed this
On Tue, 24 Feb 2009 09:41:28 +0800
Li Zefan wrote:
> >> To change the set of subsystems bound to a mounted hierarchy, just
> >> remount with different options:
> >> +# mount -o remount,cpuset,ns hier1 /dev/cgroup
> >>
> >> -# mount -o remount,cpuset,ns /dev/cgroup
> >> +Now numtasks is remov
>
> And this will get you right:
> # mount [-t cgroup] -o remount,cpu xxx /mnt
>
> Also document how to specify or change release_agent.
>
> Signed-off-by: Li Zefan
Seems nice!
Thank you.
Reviewd-by: KAMEZAWA Hiroyuki
> ---
> Documentation/cgroups/cgroups.txt
Hi,
Attached files are script to show information on console by curses.
written in ruby.
- ctop.rb
- cgroup.rb
How to use
0. mount some cgroup (cpu,memory,cpuacct,cpuset subsystems are supported)
1. put ctop.rb and cgroup.rb to a directory.
2. ruby ctop.rb
3. read help (No Manuals..)
I wro
From: KAMEZAWA Hiroyuki
Set correct permission to memcg's file.
Signed-off-by: KAMEZAWA Hiroyuki
---
mm/memcontrol.c |4
1 file changed, 4 insertions(+)
Index: mmotm-2.6.29-Feb24/mm/memcontrol.c
===
--- mmotm-2
From: KAMEZAWA Hiroyuki
cgroup's subsys has "readonly" files, but default permission is always
rw-r--r--. This allows to create r--r--r-- file to subsys.
(The user can do chmod on this read-only file. But this behavior is not
different from current pseudo file systems as /proc.)
On Thu, 26 Feb 2009 13:00:05 -0800
Andrew Morton wrote:
> On Wed, 25 Feb 2009 16:35:55 +0900
> KAMEZAWA Hiroyuki wrote:
>
> > When I wrote tools for maintain cgroup, I can't find which file is
> > writable intarfece or not via cgroup file systems. (finally,
On Thu, 26 Feb 2009 16:28:11 -0800
Paul Menage wrote:
> On Thu, Feb 26, 2009 at 1:00 PM, Andrew Morton
> wrote:
> > On Wed, 25 Feb 2009 16:35:55 +0900
> > KAMEZAWA Hiroyuki wrote:
> >
> >> When I wrote tools for maintain cgroup, I can't find which file
On Mon, 2 Mar 2009 10:19:15 -0800
Paul Menage wrote:
> On Sun, Mar 1, 2009 at 6:13 PM, Li Zefan wrote:
> > Now a cgroup subsystem can set default file mode of its control files,
> > so here is a patchset to correct file mode of each subsystem's files.
>
> I really think that we should be defaul
On Mon, 2 Mar 2009 16:15:51 -0800
Paul Menage wrote:
> On Mon, Mar 2, 2009 at 4:09 PM, KAMEZAWA Hiroyuki
> wrote:
> >
> >int mode;
> >if (cft->mode)
> >mode = cft->mode;
> >else if (cft->write_xxx || .)
&g
On Tue, 03 Mar 2009 09:08:23 +0800
Li Zefan wrote:
> Paul Menage wrote:
> > On Sun, Mar 1, 2009 at 6:13 PM, Li Zefan wrote:
> >> Now a cgroup subsystem can set default file mode of its control files,
> >> so here is a patchset to correct file mode of each subsystem's files.
> >
> > I really thi
= 0444;
> >> +
> >> + if (cft->write || cft->write_u64 || cft->write_s64 ||
> >> + cft->write_string || cft->trigger)
> >> + mode += 0200;
> >> +
> >
> > += is not |=...
> >
>
> Ah, yes, though bot
On Wed, 04 Mar 2009 09:52:57 +0800
Li Zefan wrote:
> - 'mode' should have type mode_t
> - use S_IRUGO/S_IWUSR instead of 0444/0200
>
> Signed-off-by: Li Zefan
Thank you for quick work. I'll write memcg part on this.
Reviewed-by: KAMEZAWA Hiroyuki
> ---
>
On Wed, 04 Mar 2009 09:59:53 +0800
Li Zefan wrote:
> KAMEZAWA Hiroyuki wrote:
> > On Wed, 04 Mar 2009 09:52:57 +0800
> > Li Zefan wrote:
> >
> >> - 'mode' should have type mode_t
> >> - use S_IRUGO/S_IWUSR instead of 0444/0200
> >>
On Thu, 12 Mar 2009 03:51:16 -0700
Paul Menage wrote:
> The following series implements support for:
>
> - named cgroup hierarchies
> - cgroup hierarchies with no bound subsystems
> - cgroup subsystems that can be bound to multiple hierarchies
>
> These patches aren't yet very well tested (only
On Tue, 14 Apr 2009 22:21:14 +0200
Andrea Righi wrote:
> From: Ryo Tsuruta
>
> From: Ryo Tsuruta
>
> With writeback IO processed asynchronously by kernel threads (pdflush)
> the real writes to the underlying block devices can occur in a different
> IO context respect to the task that original
On Wed, 15 Apr 2009 15:23:57 +0200
Andrea Righi wrote:
> On Wed, Apr 15, 2009 at 09:38:50PM +0900, Ryo Tsuruta wrote:
> > Hi Andrea and Kamezawa-san,
> >
> > > Ryo, it would be great if you can look at this and fix/integrate into
> > > the mainstream bio-cgroup. Otherwise I can try to to schedul
On Thu, 16 Apr 2009 12:42:36 +0200
Andrea Righi wrote:
> On Thu, Apr 16, 2009 at 08:58:14AM +0900, KAMEZAWA Hiroyuki wrote:
> > On Wed, 15 Apr 2009 15:23:57 +0200
> > Andrea Righi wrote:
> >
> > > On Wed, Apr 15, 2009 at 09:38:50PM +0900, Ryo Tsuruta wrote:
>
On Thu, 16 Apr 2009 15:29:37 -0700
Andrew Morton wrote:
> On Tue, 14 Apr 2009 22:21:14 +0200
> Andrea Righi wrote:
>
> > Subject: [PATCH 3/9] bio-cgroup controller
>
> Sorry, but I have to register extreme distress at the name of this.
> The term "bio" is well-established in the kernel and he
On Tue, 14 Apr 2009 22:21:12 +0200
Andrea Righi wrote:
> +Example:
> +* Create an association between an io-throttle group and a bio-cgroup group
> + with "bio" and "blockio" subsystems mounted in different mount points:
> + # mount -t cgroup -o bio bio-cgroup /mnt/bio-cgroup/
> + # cd /mnt/bi
On Fri, 17 Apr 2009 10:49:43 +0900
Takuya Yoshikawa wrote:
> Hi,
>
> I have a few question.
>- I have not yet fully understood how your controller are using
> bio_cgroup. If my view is wrong please tell me.
>
> o In my view, bio_cgroup's implementation strongly depends on
>page_cgo
On Fri, 17 Apr 2009 15:34:53 +0800
Gui Jianfeng wrote:
> KAMEZAWA Hiroyuki wrote:
> > On Tue, 14 Apr 2009 22:21:12 +0200
> > Andrea Righi wrote:
> >
> >> +Example:
> >> +* Create an association between an io-throttle group and a bio-cgroup
>
On Fri, 17 Apr 2009 16:22:01 +0900 (JST)
Ryo Tsuruta wrote:
> In the case where the bio-cgroup data is allocated dynamically,
>- Sometimes quite a large amount of memory get marked dirty.
> In this case it requires more kernel memory than that of the
> current implementation.
>-
On Fri, 17 Apr 2009 17:00:16 +0900
KAMEZAWA Hiroyuki wrote:
> On Fri, 17 Apr 2009 16:22:01 +0900 (JST)
> Ryo Tsuruta wrote:
>
> > In the case where the bio-cgroup data is allocated dynamically,
> >- Sometimes quite a large amount of memory get marked dirty.
>
On Fri, 17 Apr 2009 17:48:54 +0900
KAMEZAWA Hiroyuki wrote:
> On Fri, 17 Apr 2009 17:00:16 +0900
> KAMEZAWA Hiroyuki wrote:
>
> > On Fri, 17 Apr 2009 16:22:01 +0900 (JST)
> > Ryo Tsuruta wrote:
> >
> > > In the case where the bio-cgroup data is allocat
On Sat, 18 Apr 2009 23:38:27 +0200
Andrea Righi wrote:
> Introduce attributes and functions in res_counter to implement
> throttling-based
> cgroup subsystems.
>
> The following attributes have been added to struct res_counter:
> * @policy: the limiting policy / algorithm
> * @capacity:
On Sun, 19 Apr 2009 17:53:59 +0200
Andrea Righi wrote:
> >
> > Got a question for you. Does memory controller already have the per cgroup
> > dirty pages limit? If no, has this been discussed in the past? if yes,
> > what was the conclsion?
>
IMHO, dirty page handling and I/O throttling is a di
Andrea Righi wrote:
> On Tue, Apr 21, 2009 at 09:15:34AM +0900, KAMEZAWA Hiroyuki wrote:
>> It's very bad if cacheline of spinlock is different from data field, in
>> future.
>
> Regarding the new attributes, policy can be surely an unsigned int or
> even less (now o
On Tue, 21 Apr 2009 22:49:06 +0200
Andrea Righi wrote:
> yep! right. Anyway, it's not completely wrong to account dirty pages in
> this way. The dirty pages actually belong to cgroup A and providing per
> cgroup upper limits of dirty pages could help to equally distribute
> dirty pages, that are h
On Wed, 22 Apr 2009 09:33:49 +0900
KAMEZAWA Hiroyuki wrote:
> > And this should be probably strictly connected to the IO controller. If
> > we throttle or delay the dispatching/submission of some IO requests
> > without throttling the dirty pages rate a cgroup could completely
On Wed, 22 Apr 2009 12:22:41 +0200
Andrea Righi wrote:
> Actually I was proposing something quite similar, if I've understood
> well. Just add a hook in balance_dirty_pages() to throttle tasks in
> cgroups that exhausted their IO BW.
>
> The way to do so will be similar to the per-bdi write thr
On Wed, 22 Apr 2009 21:22:54 -0400
Theodore Tso wrote:
> On Thu, Apr 23, 2009 at 09:05:35AM +0900, KAMEZAWA Hiroyuki wrote:
> > So, current status is.
> >
> > A. memcg should support dirty_ratio for its own memory reclaim.
> > in plan.
> >
> >
On Wed, 22 Apr 2009 21:58:25 -0700
Andrew Morton wrote:
> > Or at least that *someone* is
> > doing so and can perhaps document how all of these knobs interact.
> > After all, if they are going to be separate, and someone turns the I/O
> > throttling knob without bothering to turn the write throt
On Thu, 23 Apr 2009 23:13:04 +0200
Andrea Righi wrote:
> On Thu, Apr 23, 2009 at 08:17:45AM -0400, Theodore Tso wrote:
> > On Thu, Apr 23, 2009 at 11:44:24AM +0200, Andrea Righi wrote:
> > > This is true in part. Actually io-throttle v12 has been largely tested,
> > > also in production environme
Hi, these are patches on my stack, now.
I believe test is not enough. Maybe there is BUG.
Before updating patches, I'd like to hear guys' advice against my concept
before going further.
TODO:
- test on NUMA (machine is not avilable in these days. but I will do)
This series inludes 2 series of
er than res->lwmark.
Maybe we can add more tunings but no extra params now.
ChangeLog:
- start "memcontd" at first change in hwmark.
(In old verion, it started at cgroup creation.)
- changed "relax" logic in memcontd daemon.
Signed-off-by: KAMEZAWA Hiroyuki &l
r background jobs...
If I have to check under lock, please teach me.
counter->hwmark and counter->lwmark is not automatically adjusted
when limit is changed. So, users must change lwmark, hwmark before
changing limit.
Changelog
* made variable names shorter.
* adjusted to 2.6.24-mm1
Signe
One of contended lock is counter->lock.
Now, counter->usage is changed by PAGE_SIZE. This patch changes
this to be PAGE_SIZE * borrow_factor and cache "borrow" in
per cpu area.
This reduce # of lock against counter->lock.
Signed-off-by: KAMEZAWA Hiroyuki <[EMAIL PRO
omtically estimated value ?
(I used '# of cpus/4' as default in previous version.)
Signed-off-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
mm/memcontrol.c | 235 ++--
1 files changed, 127 insertions(+), 108 deletions(-)
tch adds a new flag page_cgroup and make lru scan routine
ignores it.
I think this reduces lock contention especially when
- several tasks are exiting at once.
- several files are removed at once.
Signed-off-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
mm/memcontrol
On Thu, 14 Feb 2008 14:02:44 +0530
Balbir Singh <[EMAIL PROTECTED]> wrote:
> KAMEZAWA Hiroyuki wrote:
> > A patch for background reclaim based on high-low watermak in res_counter.
> > The daemon is called as "memcontd", here.
> >
> > Implements followi
On Thu, 14 Feb 2008 14:18:33 +0530
Balbir Singh <[EMAIL PROTECTED]> wrote:
> > If I have to check under lock, please teach me.
> >
>
> If there are several processes running in parallel in the same cgroup, the end
> result might not be so nice, specially if the usage is close to the
> watermarks
On Thu, 14 Feb 2008 14:44:50 +0530
Balbir Singh <[EMAIL PROTECTED]> wrote:
> > By this interface, a user can control the # of threads which can enter
> > try_to_free...
> >
>
> What happens to the other threads, do they sleep?
>
yes.
> > Default is 10240 ...a enough big number for unlimited. Ma
On Fri, 15 Feb 2008 12:44:18 -0800
Paul Menage <[EMAIL PROTECTED]> wrote:
>
> This set of patches makes the Control Groups API more structured and
> self-describing.
>
> 1) Allows control files to be associated with data types such as
> "u64", "string", "map", etc. These types show up in a new c
On Mon, 18 Feb 2008 09:53:35 +0900 (JST)
[EMAIL PROTECTED] (YAMAMOTO Takashi) wrote:
> > + /* try to charge */
> > + ret = res_counter_charge(&mem->res, mem->borrow_unit);
> > + if (!ret) { /* success */
> > + *bwp += (mem->borrow_unit - size);
> > +
On Mon, 18 Feb 2008 10:58:40 +0900 (JST)
[EMAIL PROTECTED] (YAMAMOTO Takashi) wrote:
> > + /*
> > +* For lazy freeing (not GC)
> > +*/
> > + struct {
> > + struct mem_cgroup_per_zone *mz;
> > + int num;
> > +#define GARBAGE_MAXSIZE(16
On Mon, 18 Feb 2008 10:05:16 +0530
Balbir Singh <[EMAIL PROTECTED]> wrote:
> Hi, KAMEZAWA-San,
>
> For this and the next patch, do you know if there is a performance
> improvement?
> Have we measured it. The complexity of the code seems to be high, want to make
> sure it is worth it.
I'd like to
likely(!PageLRU(page)))
> continue;
> --
> 1.5.4.rc3
>
Acked-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
Thanks,
-Kame
___
Containers mailing list
[EMAIL PROTECTED]
https://lists.linux-foundation.org/mailman/listi
On Wed, 05 Mar 2008 14:59:05 +0900
Daisuke Nishimura <[EMAIL PROTECTED]> wrote:
> #ifdef CONFIG_CGROUP_MEM_CONT
> +/*
> + * A page_cgroup page is associated with every page descriptor. The
> + * page_cgroup helps us identify information about the cgroup
> + */
> +struct page_cgroup {
> + stru
1 - 100 of 802 matches
Mail list logo