On Mon, 18 Oct 2010 17:39:37 -0700
Greg Thelen wrote:
> From: KAMEZAWA Hiroyuki
>
> From: KAMEZAWA Hiroyuki
>
> Introduce a new bit spin lock, PCG_MOVE_LOCK, to synchronize
> the page accounting and migration code. This reworks the
> locking scheme of _update_stat() and _move_account() by
>
On Mon, 18 Oct 2010 17:39:36 -0700
Greg Thelen wrote:
> Replace usage of the mem_cgroup_update_file_mapped() memcg
> statistic update routine with two new routines:
> * mem_cgroup_inc_page_stat()
> * mem_cgroup_dec_page_stat()
>
> As before, only the file_mapped statistic is managed. However,
>
From: KAMEZAWA Hiroyuki
reduce lock at account moving.
a patch "memcg: add lock to synchronize page accounting and migration" add
a new lock and make locking cost twice. This patch is for reducing the cost.
At moving charges by scanning page table, we do all jobs under pte_lock.
This means we n
On Tue, 19 Oct 2010 09:45:12 +0900
KAMEZAWA Hiroyuki wrote:
> On Mon, 18 Oct 2010 17:39:37 -0700
> Greg Thelen wrote:
>
> > Performance Impact: moving a 8G anon process.
> >
> > Before:
> > real0m0.792s
> > user0m0.000s
> > sys 0m0.780s
> >
> > After:
> > real0
On Mon, 18 Oct 2010 17:39:34 -0700
Greg Thelen wrote:
> Add additional flags to page_cgroup to track dirty pages
> within a mem_cgroup.
>
> Signed-off-by: KAMEZAWA Hiroyuki
> Signed-off-by: Andrea Righi
> Signed-off-by: Greg Thelen
Acked-by: Daisuke Nishimura
___
From: KAMEZAWA Hiroyuki
From: KAMEZAWA Hiroyuki
Introduce a new bit spin lock, PCG_MOVE_LOCK, to synchronize
the page accounting and migration code. This reworks the
locking scheme of _update_stat() and _move_account() by
adding new lock bit PCG_MOVE_LOCK, which is always taken
under IRQ disab
On Tue, Oct 19, 2010 at 9:39 AM, Greg Thelen wrote:
> From: KAMEZAWA Hiroyuki
>
> From: KAMEZAWA Hiroyuki
>
> Introduce a new bit spin lock, PCG_MOVE_LOCK, to synchronize
> the page accounting and migration code. This reworks the
> locking scheme of _update_stat() and _move_account() by
> addin
On Mon, 18 Oct 2010 17:39:44 -0700
Greg Thelen wrote:
> If the current process is in a non-root memcg, then
> global_dirty_limits() will consider the memcg dirty limit.
> This allows different cgroups to have distinct dirty limits
> which trigger direct and background writeback at different
> lev
On Mon, 18 Oct 2010 17:39:43 -0700
Greg Thelen wrote:
> The determine_dirtyable_memory() function is not used outside of
> page writeback. Make the routine static. No functional change.
> Just a cleanup in preparation for a change that adds memcg dirty
> limits consideration into global_dirty_l
If the current process is in a non-root memcg, then
global_dirty_limits() will consider the memcg dirty limit.
This allows different cgroups to have distinct dirty limits
which trigger direct and background writeback at different
levels.
Signed-off-by: Andrea Righi
Signed-off-by: Greg Thelen
---
On Mon, 18 Oct 2010 17:39:42 -0700
Greg Thelen wrote:
> Add cgroupfs interface to memcg dirty page limits:
> Direct write-out is controlled with:
> - memory.dirty_ratio
> - memory.dirty_limit_in_bytes
>
> Background write-out is controlled with:
> - memory.dirty_background_ratio
> -
On Mon, 18 Oct 2010 17:39:41 -0700
Greg Thelen wrote:
> From: Balbir Singh
>
> memcg has lockdep warnings (sleep inside rcu lock)
>
> From: Balbir Singh
>
> Recent move to get_online_cpus() ends up calling get_online_cpus() from
> mem_cgroup_read_stat(). However mem_cgroup_read_stat() is cal
Add memcg routines to track dirty, writeback, and unstable_NFS pages.
These routines are not yet used by the kernel to count such pages.
A later change adds kernel calls to these new routines.
Signed-off-by: Greg Thelen
Signed-off-by: Andrea Righi
---
Changelog since v1:
- Renamed "nfs"/"total_
On Mon, 18 Oct 2010 17:39:36 -0700
Greg Thelen wrote:
> Replace usage of the mem_cgroup_update_file_mapped() memcg
> statistic update routine with two new routines:
> * mem_cgroup_inc_page_stat()
> * mem_cgroup_dec_page_stat()
>
> As before, only the file_mapped statistic is managed. However,
>
On Mon, 18 Oct 2010 17:39:40 -0700
Greg Thelen wrote:
> Extend mem_cgroup to contain dirty page limits. Also add routines
> allowing the kernel to query the dirty usage of a memcg.
>
> These interfaces not used by the kernel yet. A subsequent commit
> will add kernel calls to utilize these new
On Mon, 18 Oct 2010 17:39:39 -0700
Greg Thelen wrote:
> Add calls into memcg dirty page accounting. Notify memcg when pages
> transition between clean, file dirty, writeback, and unstable nfs.
> This allows the memory controller to maintain an accurate view of
> the amount of its memory that is
On Mon, 18 Oct 2010 17:39:38 -0700
Greg Thelen wrote:
> Add memcg routines to track dirty, writeback, and unstable_NFS pages.
> These routines are not yet used by the kernel to count such pages.
> A later change adds kernel calls to these new routines.
>
> Signed-off-by: Greg Thelen
> Signed-of
On Mon, 18 Oct 2010 17:39:35 -0700
Greg Thelen wrote:
> Document cgroup dirty memory interfaces and statistics.
>
> Signed-off-by: Andrea Righi
> Signed-off-by: Greg Thelen
I think you don't need to drop Ack if you have no major changes.
Acked-by: KAMEZAWA Hiroyuki
On Mon, 18 Oct 2010 17:39:37 -0700
Greg Thelen wrote:
> Performance Impact: moving a 8G anon process.
>
> Before:
> real0m0.792s
> user0m0.000s
> sys 0m0.780s
>
> After:
> real0m0.854s
> user0m0.000s
> sys 0m0.842s
>
> This score is b
Add calls into memcg dirty page accounting. Notify memcg when pages
transition between clean, file dirty, writeback, and unstable nfs.
This allows the memory controller to maintain an accurate view of
the amount of its memory that is dirty.
Signed-off-by: Greg Thelen
Signed-off-by: Andrea Righi
Replace usage of the mem_cgroup_update_file_mapped() memcg
statistic update routine with two new routines:
* mem_cgroup_inc_page_stat()
* mem_cgroup_dec_page_stat()
As before, only the file_mapped statistic is managed. However,
these more general interfaces allow for new statistics to be
more eas
Document cgroup dirty memory interfaces and statistics.
Signed-off-by: Andrea Righi
Signed-off-by: Greg Thelen
---
Changelog since v1:
- Renamed "nfs"/"total_nfs" to "nfs_unstable"/"total_nfs_unstable" in per cgroup
memory.stat to match /proc/meminfo.
- Allow [kKmMgG] suffixes for newly crea
Add additional flags to page_cgroup to track dirty pages
within a mem_cgroup.
Signed-off-by: KAMEZAWA Hiroyuki
Signed-off-by: Andrea Righi
Signed-off-by: Greg Thelen
---
include/linux/page_cgroup.h | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/
The determine_dirtyable_memory() function is not used outside of
page writeback. Make the routine static. No functional change.
Just a cleanup in preparation for a change that adds memcg dirty
limits consideration into global_dirty_limits().
Signed-off-by: Andrea Righi
Signed-off-by: Greg Thele
From: Balbir Singh
memcg has lockdep warnings (sleep inside rcu lock)
From: Balbir Singh
Recent move to get_online_cpus() ends up calling get_online_cpus() from
mem_cgroup_read_stat(). However mem_cgroup_read_stat() is called under rcu
lock. get_online_cpus() can sleep. The dirty limit patches
Add cgroupfs interface to memcg dirty page limits:
Direct write-out is controlled with:
- memory.dirty_ratio
- memory.dirty_limit_in_bytes
Background write-out is controlled with:
- memory.dirty_background_ratio
- memory.dirty_background_limit_bytes
Other memcg cgroupfs files support
Extend mem_cgroup to contain dirty page limits. Also add routines
allowing the kernel to query the dirty usage of a memcg.
These interfaces not used by the kernel yet. A subsequent commit
will add kernel calls to utilize these new routines.
Signed-off-by: Greg Thelen
Signed-off-by: Andrea Righ
Changes since v2:
- Rather than disabling softirq in lock_page_cgroup(), introduce a separate lock
to synchronize between memcg page accounting and migration. This only affects
patch 4 of the series. Patch 4 used to disable softirq, now it introduces the
new lock.
Changes since v1:
- Renam
KAMEZAWA Hiroyuki writes:
> On Sun, 3 Oct 2010 23:57:55 -0700
> Greg Thelen wrote:
>
>> Greg Thelen (10):
>> memcg: add page_cgroup flags for dirty page tracking
>> memcg: document cgroup dirty memory interfaces
>> memcg: create extensible page stat update routines
>> memcg: disable loc
MH> If we postpone clearing the object hash until restart returns to
MH> userspace there can be a race where the restarted tasks behave
MH> differently due to the references held by the objhash. One
MH> specific example of this is restarting half-closed pipes. Without
MH> this patch we've got a r
Le 12/10/2010 07:05, KAMEZAWA Hiroyuki a écrit :
> On Fri, 08 Oct 2010 10:09:51 +0200
> MALATTAR wrote:
>
>> Le 07/10/2010 16:43, MALATTAR a écrit :
>>>
>>> 06.10.2010 23:41, MALATTAR ?:
>>>
/ the container dora1,
Hi all,
I subscribed in this list recently and i have some questions about lxc
performance.
firstly, let me explain where i am using lxc:
i am using lxc with ns3 in order to simulate adhoc network where i will
test my IDS(intrusion detection system for adhoc routing protocol).
i create until no
Le 08/10/2010 18:41, Serge E. Hallyn a écrit :
> Quoting MALATTAR (mouhannad.alat...@univ-fcomte.fr):
>>
>> Message original
>> Sujet: Re: lxc-performance
>> Date : Thu, 07 Oct 2010 16:56:05 +0200
>> De : MALATTAR
>> Pour : MALATTAR
>>
>>
>>
>> Le 07/10
Hi every body,
I'm a newbie to container use.
I am going to use the libnetfilter_queue, an userspace library, to
forward the packets that have been queued by the kernel packet filter,
such like iptables,
to userspace program but it didn't work. Do anyone else has been try
this way before or had a
Message original
Sujet: Re: lxc-performance
Date : Thu, 07 Oct 2010 16:56:05 +0200
De :MALATTAR
Pour : MALATTAR
Le 07/10/2010 16:43, MALATTAR a écrit :
>
> 06.10.2010 23:41, MALATTAR ?:
>
>
Greg Thelen wrote:
> Add cgroupfs interface to memcg dirty page limits:
> Direct write-out is controlled with:
> - memory.dirty_ratio
> - memory.dirty_bytes
>
> Background write-out is controlled with:
> - memory.dirty_background_ratio
> - memory.dirty_background_bytes
>
> Signed-off-by
Hello Andrew,
On Thu, 2010-09-23 at 13:11 -0700, Andrew Morton wrote:
> > GOALS OF THIS PATCH SET
> > ---
> > The intention of this patch set is to provide better support for tools like
> > top. The goal is to:
> >
> > * provide a task snapshot mechanism where we can get a con
On Thu, Sep 23, 2010 at 09:32:29AM -0700, Eric W. Biederman wrote:
> > At several occasions, I was left with either some runaway daemon which
> > kept the namespace alive. To describe this a little more graphically:
> > I found no other way than doing a
> > md5sum /proc/*/net/if_inet6 | sort |
(Trimming To/Cc heavily)
Hello,
On Thursday 23 September 2010, Eric W. Biederman wrote:
> Introduce file for manipulating namespaces and related syscalls.
> files:
> /proc/self/ns/
>
> syscalls:
> int setns(unsigned long nstype, int fd);
> socketat(int nsfd, int family, int type, int protocol
Eric W. Biederman wrote:
> Introduce file for manipulating namespaces and related syscalls.
> files:
> /proc/self/ns/
>
> syscalls:
> int setns(unsigned long nstype, int fd);
> socketat(int nsfd, int family, int type, int protocol);
>
How does security work? Are there different kinds of fd that
Hello Andrew,
On Fri, 2010-09-24 at 11:50 -0700, Andrew Morton wrote:
> > > This is a big change! If this is done right then we're heading in the
> > > direction of deprecating the longstanding way in which userspace
> > > observes the state of Linux processes and we're recommending that the
> >
On Fri, Sep 24, 2010 at 07:51:24AM -0400, jamal wrote:
> > migrating route table entries makes no sense because
> > a) they refer to devices and configuration that does not exist in the
> >target namespace; they only make sense within their netns context
> > b) they are purely virtual and you g
Greg Thelen wrote:
> Balbir Singh writes:
>
>> * Greg Thelen [2010-10-03 23:57:55]:
>>
>>
>>> This patch set provides the ability for each cgroup to have independent
>>> dirty
>>> page limits.
>>>
>>> Limiting dirty memory is like fixing the max amount of dirty (hard to
>>> reclaim)
>>>
Greg Thelen wrote:
> Ciju Rajan K writes:
>
>
>> Greg Thelen wrote:
>>
>>> Replace usage of the mem_cgroup_update_file_mapped() memcg
>>> statistic update routine with two new routines:
>>> * mem_cgroup_inc_page_stat()
>>> * mem_cgroup_dec_page_stat()
>>>
>>> As before, only the file_mappe
From: Evgeny Kuznetsov
Function "strcpy" is used without check for maximum allowed source
string length and could cause destination string overflow.
Check for string length is added before using "strcpy".
Function now is return error if source string length is more than
a maximum.
Signed-off-by:
Hi,
Here is patch which fixes minor bug in /kernel/cgroup.c file.
Function "strcpy" is used without check for maximum allowed source
string length and could cause destination string overflow.
Thanks,
Best Regards,
Evgeny
Evgeny Kuznetsov (1):
cgroups: strcpy destination string overflow
kerne
Greg Thelen wrote:
> Replace usage of the mem_cgroup_update_file_mapped() memcg
> statistic update routine with two new routines:
> * mem_cgroup_inc_page_stat()
> * mem_cgroup_dec_page_stat()
>
> As before, only the file_mapped statistic is managed. However,
> these more general interfaces allow f
On Fri, Sep 24, 2010 at 09:32:53AM -0400, jamal wrote:
> On Fri, 2010-09-24 at 14:57 +0200, David Lamparter wrote:
> > No. While you sure could associate routes with devices, they don't
> > *functionally* reside on top of network devices. They reside on top of
> > the entire IP configuration,
>
>
Hello Matt,
On Thu, 2010-09-23 at 15:11 -0700, Matt Helsley wrote:
> > Talk to me about namespaces, please. A lot of the new code involves
> > PIDs, but PIDs are not system-wide unique. A PID is relative to a PID
> > namespace. Does everything Just Work? When userspace sends a PID to
> > the k
On Thu, Sep 23, 2010 at 01:45:04AM -0700, Eric W. Biederman wrote:
> Introduce file for manipulating namespaces and related syscalls.
> files:
> /proc/self/ns/
As feedback from using network namespaces extensively in more or less
production setups, I would like to make a request/suggestion: there
On Thu, Sep 23, 2010 at 07:22:06AM -0400, jamal wrote:
> On Thu, 2010-09-23 at 01:51 -0700, Eric W. Biederman wrote:
> > Take advantage of the new abstraction and allow network devices
> > to be placed in any network namespace that we have a fd to talk
> > about.
>
> So ... why just netdevice? cou
On Thu, Sep 23, 2010 at 04:34:37PM +0400, Pavel Emelyanov wrote:
> On 09/23/2010 04:11 PM, jamal wrote:
> > On Thu, 2010-09-23 at 15:53 +0400, Pavel Emelyanov wrote:
> >
> >> Why does it matter? You told, that the usage scenario was to
> >> add routes to container. If I do 2 syscalls instead of 1,
On Mon, Sep 20, 2010 at 2:12 PM, Andi Kleen wrote:
>> The pipe process needs to run in the namespaces of the process who set
>> the core pattern, not in the namespaces of the dumping process.
>> Otherwise it is possible to trigger a privileged process to run in a
>> context where it's reality that
On Mon, Sep 20, 2010 at 1:50 PM, Oleg Nesterov wrote:
> On 09/17, Will Drewry wrote:
>>
>> On Fri, Sep 17, 2010 at 8:29 PM, Oleg Nesterov wrote:
>> >
>> > This looks overcomplicated to me, or I missed something.
>> >
>> > I do not understand why should we do this beforehand, and why we need
>> >
On Fri, Sep 17, 2010 at 9:34 PM, Will Drewry wrote:
> On Fri, Sep 17, 2010 at 8:29 PM, Oleg Nesterov wrote:
>> On 09/17, Will Drewry wrote:
>>>
>>> Instead, this change implements the more complex option two. It
>>> migrates the call_usermodehelper() thread into the same namespaces
>>> as th
On Fri, Sep 17, 2010 at 8:29 PM, Oleg Nesterov wrote:
> On 09/17, Will Drewry wrote:
>>
>> Instead, this change implements the more complex option two. It
>> migrates the call_usermodehelper() thread into the same namespaces
>> as the dumping process. It does not assign a pid in that namespa
On Fri, Sep 17, 2010 at 10:16:58AM -0500, Will Drewry wrote:
> Presently, a core_pattern pipe endpoint will be run in the init
> namespace. It will receive the virtual pid (task_tgid_vnr->%p) of the
> core dumping process but will have no access to that processes /proc
> without walking the init n
Presently, a core_pattern pipe endpoint will be run in the init
namespace. It will receive the virtual pid (task_tgid_vnr->%p) of the
core dumping process but will have no access to that processes /proc
without walking the init namespace /proc looking through all the global
pids until it finds the
This changes adds copy_namespaces_unattached which provides similar
behavior to copy_namespaces() for clone, but is meant for use when a
new namespace needs to be derived from an existing process outside
of process creation.
The next patch in this series shows this function used in fs/exec.c to
in
On Thu, Sep 16, 2010 at 3:12 PM, Eric W. Biederman
wrote:
> Oleg Nesterov writes:
>
>> On 09/16, Will Drewry wrote:
>>>
>>> --- a/fs/exec.c
>>> +++ b/fs/exec.c
>>> @@ -1467,6 +1467,13 @@ static int format_corename(char *corename, long
>>> signr)
>>> char *const out_end = corename + CORENAME
format_corename uses task_tgid_vnr to provide the numeric pid of a
core-dumping process. For file-based coredumps, this is perfectly
satisfactory. However, when the core_pattern contains a pipe, the
substituted PID is invalid in the namespace of the core_pattern pipe
helper, the init namespace.
On Fri, Sep 17, 2010 at 8:26 AM, Andi Kleen wrote:
> On Thu, 16 Sep 2010 13:59:59 -0500
> Will Drewry wrote:
>
>> format_corename uses task_tgid_vnr to provide the numeric pid of a
>> core-dumping process. For file-based coredumps, this is perfectly
>> satisfactory. However, when the core_patte
Presently, a core_pattern pipe endpoint will be run in the init
namespace. It will receive the virtual pid (task_tgid_vnr->%p) of the
core dumping process but will have no access to that processes /proc
without walking the init namespace /proc looking through all the global
pids until it finds the
On Fri, Sep 17, 2010 at 1:15 PM, Neil Horman wrote:
> On Fri, Sep 17, 2010 at 10:16:58AM -0500, Will Drewry wrote:
>> Presently, a core_pattern pipe endpoint will be run in the init
>> namespace. It will receive the virtual pid (task_tgid_vnr->%p) of the
>> core dumping process but will have no a
64 matches
Mail list logo
