Li Zefan wrote:
Andrea Righi wrote:
This is the core io-throttle kernel infrastructure. It creates the basic
interfaces to cgroups and implements the I/O measurement and throttling
functions.
Signed-off-by: Andrea Righi [EMAIL PROTECTED]
---
block/Makefile|2 ++
With this series of bio-cgruop patches, you can determine the owners of any
type of I/Os and it makes dm-ioband -- I/O bandwidth controller --
be able to control the Block I/O bandwidths even when it accepts
delayed write requests.
Dm-ioband can find the owner cgroup of each request.
It is also
This patch splits the cgroup memory subsystem into two parts.
One is for tracking pages to find out the owners. The other is
for controlling how much amount of memory should be assigned to
each cgroup.
With this patch, you can use the page tracking mechanism even if
the memory subsystem is off.
Here is the documentation of design overview, installation, command
reference and examples.
Based on 2.6.27-rc1-mm1
Signed-off-by: Ryo Tsuruta [EMAIL PROTECTED]
Signed-off-by: Hirokazu Takahashi [EMAIL PROTECTED]
diff -uprN linux-2.6.27-rc1-mm1.orig/Documentation/device-mapper/ioband.txt
Hi everyone,
This series of patches of dm-ioband now includes The bio tracking mechanism,
which has been posted individually to this mailing list.
This makes it easy for anybody to control the I/O bandwidth even when
the I/O is one of delayed-write requests.
Have fun!
This series of patches
With this patch, dm-ioband can work with the bio cgroup.
Based on 2.6.27-rc1-mm1
Signed-off-by: Ryo Tsuruta [EMAIL PROTECTED]
Signed-off-by: Hirokazu Takahashi [EMAIL PROTECTED]
diff -Ndupr linux-2.6.27-rc1-mm1.cg2/drivers/md/dm-ioband-type.c
linux-2.6.27-rc1-mm1.cg3/drivers/md/dm-ioband-type.c
This patch implements the bio cgroup on the memory cgroup.
Based on 2.6.27-rc1-mm1
Signed-off-by: Ryo Tsuruta [EMAIL PROTECTED]
Signed-off-by: Hirokazu Takahashi [EMAIL PROTECTED]
diff -Ndupr linux-2.6.27-rc1-mm1.cg1/block/blk-ioc.c
linux-2.6.27-rc1-mm1.cg2/block/blk-ioc.c
---
This patch is for cleaning up the code of the cgroup memory subsystem
to remove a lot of #ifdefs.
Based on 2.6.27-rc1-mm1
Signed-off-by: Ryo Tsuruta [EMAIL PROTECTED]
Signed-off-by: Hirokazu Takahashi [EMAIL PROTECTED]
diff -Ndupr linux-2.6.27-rc1-mm1.cg0/mm/memcontrol.c
On Fri, Aug 01, 2008 at 02:51:57PM -0400, Oren Laadan wrote:
Louis Rilling wrote:
On Fri, Aug 01, 2008 at 10:15:26AM -0400, Oren Laadan wrote:
Louis Rilling wrote:
On Thu, Jul 31, 2008 at 03:12:32PM -0400, Oren Laadan wrote:
Cut the less interesting (IMHO at least) history to make Dave
On Mon, 2008-08-04 at 17:51 +0900, Ryo Tsuruta wrote:
This series of patches of dm-ioband now includes The bio tracking mechanism,
which has been posted individually to this mailing list.
This makes it easy for anybody to control the I/O bandwidth even when
the I/O is one of delayed-write
Dave Hansen wrote:
On Mon, 2008-08-04 at 17:51 +0900, Ryo Tsuruta wrote:
This series of patches of dm-ioband now includes The bio tracking
mechanism,
which has been posted individually to this mailing list.
This makes it easy for anybody to control the I/O bandwidth even when
the I/O is one
Dave Hansen wrote:
On Mon, 2008-08-04 at 17:51 +0900, Ryo Tsuruta wrote:
This series of patches of dm-ioband now includes The bio tracking
mechanism,
which has been posted individually to this mailing list.
This makes it easy for anybody to control the I/O bandwidth even when
the I/O is one
On Mon, 2008-08-04 at 20:22 +0200, Andrea Righi wrote:
But I'm not yet convinced that limiting the IO writes at the device
mapper layer is the best solution. IMHO it would be better to throttle
applications' writes when they're dirtying pages in the page cache (the
io-throttle way), because
Hugh Dickins wrote:
[snip]
BUG: unable to handle kernel paging request at 6b6b6b8b
IP: [7817078f] memrlimit_cgroup_uncharge_as+0x18/0x29
*pde =
Oops: [#1] PREEMPT SMP
last sysfs file: /sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map
Modules linked in: acpi_cpufreq
The original version of Oren's patch contained a good hunk
of #ifdefs. I've extracted all of those and created a bit
of an API for new architectures to follow.
Leaving Oren's sign-off because this is all still his code,
even though he hasn't seen it mangled like this before.
Signed-off-by:
For each vma, there is a 'struct cr_vma'; if the vma is file-mapped,
it will be followed by the file name. The cr_vma-npages will tell
how many pages were dumped for this vma. Then it will be followed
by the actual data: first a dump of the addresses of all dumped
pages (npages entries)
I've done a bit of refactoring to Oren's patches.
I wonder if they're in a state that people think we can
share on LKML like Ted suggested. Thoughts?
--
At the containers mini-conference before OLS, the consensus among
all the stakeholders was that doing checkpoint/restart in the kernel
as
From: Oren Laadan [EMAIL PROTECTED]
This patch adds those interfaces, as well as all of the helpers
needed to easily manage the file format.
The code is roughly broken out as follows:
ckpt/sys.c - user/kernel data transfer, as well as setting up of the
checkpoint/restart context
Balbir Singh wrote:
Dave Hansen wrote:
On Mon, 2008-08-04 at 17:51 +0900, Ryo Tsuruta wrote:
This series of patches of dm-ioband now includes The bio tracking
mechanism,
which has been posted individually to this mailing list.
This makes it easy for anybody to control the I/O bandwidth even
Dave Hansen wrote:
On Mon, 2008-08-04 at 20:22 +0200, Andrea Righi wrote:
But I'm not yet convinced that limiting the IO writes at the device
mapper layer is the best solution. IMHO it would be better to throttle
applications' writes when they're dirtying pages in the page cache (the
On Mon, 2008-08-04 at 22:44 +0200, Andrea Righi wrote:
Dave Hansen wrote:
On Mon, 2008-08-04 at 20:22 +0200, Andrea Righi wrote:
But I'm not yet convinced that limiting the IO writes at the device
mapper layer is the best solution. IMHO it would be better to throttle
applications' writes
On Tue, 5 Aug 2008, Balbir Singh wrote:
Hugh Dickins wrote:
[snip]
BUG: unable to handle kernel paging request at 6b6b6b8b
IP: [7817078f] memrlimit_cgroup_uncharge_as+0x18/0x29
Pid: 22500, comm: swapoff Not tainted (2.6.26-rc8-mm1 #7)
[78161323] ? exit_mmap+0xaf/0x133
[781226b1] ?
On Sat, 2008-08-02 at 00:53 +0200, Rafael J. Wysocki wrote:
On Friday, 1 of August 2008, Matt Helsley wrote:
On Fri, 2008-08-01 at 16:27 +0200, Thomas Petazzoni wrote:
Hi,
Le Thu, 31 Jul 2008 22:07:01 -0700,
Matt Helsley [EMAIL PROTECTED] a écrit :
--- a/kernel/Makefile
I thought I will send out the patches I mentioned to H. Peter Anvin
recently to get some feedback on the general direction. This version
of the patchset ducks the user-space issue, for now.
---
Enable multiple mounts of devpts filesystem so each container can
allocate ptys independently.
To
From: Sukadev Bhattiprolu [EMAIL PROTECTED]
Subject: [RFC][PATCH 1/6] Pass-in 'struct inode' to devpts interfaces
Pass-in an 'inode' parameter to devpts interfaces. The parameter
itself will be used in subsequent patches to identify the instance
of devpts mounted.
---
drivers/char/pty.c
From: Sukadev Bhattiprolu [EMAIL PROTECTED]
Subject: [RFC][PATCH 2/6] Remove 'devpts_root' global
Remove the 'devpts_root' global variable and find the root dentry using
the super_block. The super-block itself is found from the device inode,
using a new wrapper, pts_sb_from_inode().
---
From: Sukadev Bhattiprolu [EMAIL PROTECTED]
Subject: [RFC][PATCH 4/6]: Allow mknod of ptmx in devpts
/dev/ptmx is closely tied to the devpts filesystem. An open of /dev/ptmx,
allocates the next pty index and the associated device shows up in the
devpts fs as /dev/pts/n.
Wih multiple mounts of
From: Sukadev Bhattiprolu [EMAIL PROTECTED]
Subject: [RFC][PATCH 3/6] Move 'allocated_ptys' to sb-s_s_fs_info
To enable multiple mounts of devpts, 'allocated_ptys' must be a per-mount
variable rather than a global variable. This patch moves 'allocated_ptys'
into the super_block's s_fs_info.
From: Sukadev Bhattiprolu [EMAIL PROTECTED]
Subject: [RFC][PATCH 6/6]: /dev/tty tweak in init_dev()
When opening /dev/tty, __tty_open() finds the tty using get_current_tty().
When __tty_open() calls init_dev(), init_dev() tries to 'find' the tty
again from devpts. Is that really necessary ?
From: Sukadev Bhattiprolu [EMAIL PROTECTED]
Subject: [RFC][PATCH 5/6] Allow multiple mounts of devpts
Can we simply enable multiple mounts using get_sb_nodev(), now that we
don't have any pts_namespace/'data' to be saved ?
(quick/dirty - does not prevent multiple mounts of devpts within
a
[EMAIL PROTECTED] wrote:
If devpts is mounted more than once, then '/dev/ptmx' must be a symlink
to '/dev/pts/ptmx' and in each new devpts mount we must create the
device node '/dev/pts/ptmx' [c, 5;2] by hand.
This should be auto-created. That also eliminates any need to support
the
H. Peter Anvin [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
If devpts is mounted more than once, then '/dev/ptmx' must be a symlink
to '/dev/pts/ptmx' and in each new devpts mount we must create the
device node '/dev/pts/ptmx' [c, 5;2] by hand.
This should be auto-created. That also
[EMAIL PROTECTED] wrote:
Appreciate comments on overall approach of my mapping from the inode
to sb-s_fs_info to allocated_ptys and the hacky use of get_sb_nodev(),
and also on the tweak to init_dev() (patch 6).
First of all, thanks for taking this on :) It's always delightful to
spout
[EMAIL PROTECTED] wrote:
Ok. But was wondering if we can pass the ptmx symlink burden to the
'container-startup sripts' since they are the ones that need the second
or subsequent mount of devpts.
So, initially and for systems that don't need multiple mounts of devpts,
existing behavior
Louis Rilling wrote:
On Fri, Aug 01, 2008 at 02:51:57PM -0400, Oren Laadan wrote:
Louis Rilling wrote:
On Fri, Aug 01, 2008 at 10:15:26AM -0400, Oren Laadan wrote:
Louis Rilling wrote:
On Thu, Jul 31, 2008 at 03:12:32PM -0400, Oren Laadan wrote:
Cut the less interesting (IMHO at least)
Hi, Andrea.
I participated in Containers Mini-summit.
And, I talked with Mr. Andrew Morton in The Linux Foundation Japan
Symposium BoF, Japan, July 10th.
Currently, in ML, some I/O controller patches is sent and the respective
patch keeps sending the improvement version.
We and maintainers
Hugh Dickins wrote:
On Tue, 5 Aug 2008, Balbir Singh wrote:
Hugh Dickins wrote:
[snip]
BUG: unable to handle kernel paging request at 6b6b6b8b
IP: [7817078f] memrlimit_cgroup_uncharge_as+0x18/0x29
Pid: 22500, comm: swapoff Not tainted (2.6.26-rc8-mm1 #7)
[78161323] ? exit_mmap+0xaf/0x133
On Mon, Aug 4, 2008 at 1:44 PM, Andrea Righi [EMAIL PROTECTED] wrote:
A safer approach IMHO is to force the tasks to wait synchronously on
each operation that directly or indirectly generates i/o.
In particular the solution used by the io-throttle controller to limit
the dirty-ratio in
38 matches
Mail list logo
