[I am CCing David here as well]
On Tue 30-07-13 09:37:46, Eric W. Biederman wrote:
> Michal Hocko writes:
>
> > On Tue 30-07-13 01:19:31, Eric W. Biederman wrote:
> > [...]
> >> Hmm. Looking farther I see what is going on. And it has nothing to do
> >> wit
P config to my testing configs.
Andrew, could you pick up the following patch, please?
---
>From 94048cdb5f8370987a08ea07289854a4eb41d57b Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Thu, 1 Aug 2013 09:50:28 +0200
Subject: [PATCH] include/linux/smp.h: define __smp_call_function_single
On Wed 31-07-13 15:09:16, Eric W. Biederman wrote:
> Michal Hocko writes:
>
> > [I am CCing David here as well]
> >
> > On Tue 30-07-13 09:37:46, Eric W. Biederman wrote:
> >> Michal Hocko writes:
> >>
> >> > On Tue 30-07-13 01:19:31, Eric
start to use this flag eventually.
I guess we do not care about those. If somebody wants to shoot his feet
then we cannot do much about it. The primary motivation was to find out
those that think this is right and they are willing to change the setup
once they know this is not the right way to do things.
I think that giving a way to suppress the warning is a good step. Log
level might be to coarse and sysctl would be an overkill.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
is patch shouldn't cause any behavior differences.
>
> Signed-off-by: Tejun Heo
> Cc: Aneesh Kumar K.V
> Cc: KAMEZAWA Hiroyuki
> Cc: Michal Hocko
> Cc: Johannes Weiner
Reviewed-by: Michal Hocko
> ---
> mm/hugetlb_cgroup.c | 22 --
> 1 file ch
e_css(), unnecessary open coded css
> dereference is replaced with local variable access.
>
> This patch shouldn't cause any behavior differences.
>
> Signed-off-by: Tejun Heo
> Cc: Li Zefan
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Johannes Weiner
> Cc:
t; * devices: cgroup_to_devcgroup() is no longer used. Removed.
>
> Signed-off-by: Tejun Heo
> Cc: Li Zefan
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Balbir Singh
> Cc: Aristeu Rozanski
> Cc: Matt Helsley
> Cc: Vivek Goyal
> Cc: Jens Axboe
For memcg p
ejun Heo
> Cc: Matt Helsley
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Balbir Singh
Makes sense
Acked-by: Michal Hocko
> ---
> include/linux/cgroup.h | 31 -
> kernel/cgroup.c | 114
>
&
nd functions.
>
> This patch doesn't introduce any behavior differences.
>
> Signed-off-by: Tejun Heo
> Cc: Matt Helsley
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Balbir Singh
For memcg part
Acked-by: Michal Hocko
> ---
> include/linux/cgroup
roduce any behavior differences.
>
> Signed-off-by: Tejun Heo
> Cc: Li Zefan
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Balbir Singh
> Cc: Matt Helsley
For memcg part
Acked-by: Michal Hocko
> ---
> include/linux/cgroup.h | 21 -
> ker
rsion is mostly mechanical and removes the last users of
> mem_cgroup_from_cont() and cg_to_vmpressure(), which are removed.
>
> Signed-off-by: Tejun Heo
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Balbir Singh
Acked-by: Michal Hocko
> ---
> include/linux
On Fri 02-08-13 15:19:01, Michal Hocko wrote:
[...]
> mem_cgroup_from_cont can go away now as well. Do you plan to remove it
> in the series or later on?
Ohh, it goes in 21/23. Good
Thanks!
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux
claration of function
> ‘__smp_call_function_single’ [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
> make[1]: *** [kernel/watchdog.o] Error 1
I have already sent a patch to fix this here:
https://lkml.org/lkml/2013/8/1/104
Sorry about inconvenience.
--
M,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Fri 02-08-13 16:47:10, Johannes Weiner wrote:
> On Fri, Aug 02, 2013 at 06:27:22PM +0200, Michal Hocko wrote:
> > On Fri 02-08-13 11:07:56, Joonsoo Kim wrote:
> > > We rarely allocate a page with ALLOC_NO_WATERMARKS and it is used
> > > in slow path. For making fast p
nt a message for all those
users initially. It is a matter of user how to deal with it.
> But we never want to know who is the right users, right?
Well, those that are curious about a new message in the lock and come
back to us asking what is going on are those we are primarily interes
rge_common would be confused and charge such a
page as order-0
> Signed-off-by: Kirill A. Shutemov
> Cc: Michal Hocko
> Cc: KAMEZAWA Hiroyuki
> Acked-by: Dave Hansen
Other than that, looks good to me.
Acked-by: Michal Hocko
> ---
> mm/memcontrol.c | 2 --
> 1 file ch
On Sun 04-08-13 21:13:44, KOSAKI Motohiro wrote:
> On Sun, Aug 4, 2013 at 4:07 AM, Michal Hocko wrote:
> > On Sat 03-08-13 16:16:58, KOSAKI Motohiro wrote:
> >> >>> You missed the "!". I'm proposing that setting the new bit 2 will
> >> >>&
is a matter of taste. I do not like new *likely annotations if they
do not make difference. But no strong objections if others like it.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.o
.
>
> Signed-off-by: Johannes Weiner
Looks better
Acked-by: Michal Hocko
Thanks
> ---
> include/linux/memcontrol.h | 44
> include/linux/sched.h | 3 +++
> mm/filemap.c | 11 ++-
> mm/memco
ack with
>-ENOMEM. pagefault_out_of_memory() will then call back into the
>memcg code to check if the -ENOMEM came from the memcg, and then
>either put the task to sleep on the memcg's OOM waitqueue or just
>restart the fault. The OOM victim can no longer get stuck o
e
replacement for those notifications? Or do you think that controller
shouldn't be signaling any conditions to the userspace at all?
[...]
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ma
On Mon 19-08-13 12:35:12, Johannes Weiner wrote:
> On Tue, Jun 18, 2013 at 02:09:39PM +0200, Michal Hocko wrote:
> > Hi,
> >
> > This is the fifth version of the patchset.
> >
> > Summary of versions:
> > The first version has been poste
[I am mostly offline for the whole week with very limitted internet
access so it will get longer for me to respond to emails. Sorry about
that]
On Tue 20-08-13 10:13:39, Johannes Weiner wrote:
> On Tue, Aug 20, 2013 at 11:14:14AM +0200, Michal Hocko wrote:
> > On Mon 19-08-13 12:35:12,
On Mon 05-08-13 12:29:58, Tejun Heo wrote:
> Hello, Michal.
>
> On Mon, Aug 05, 2013 at 06:01:07PM +0200, Michal Hocko wrote:
> > Could you be more specific about what is so "overboard" about this
> > interface? I am not familiar with internals much, so I cannot jud
On Mon 05-08-13 15:44:31, Tejun Heo wrote:
> Hey, Michal.
>
> On Mon, Aug 05, 2013 at 09:16:41PM +0200, Michal Hocko wrote:
[...]
> > Besides that, is fsnotify really an interface to be used under memory
> > pressure? I might be wrong but from a quick look fsnotify depe
__
>
> Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
> Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
> Geschäftsführer: Matthias Kaussen
> Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
>
> www.karo-electronics.
ue is more or less random. The
expectation is that it should be high enough to cover reasonable
usecases while not too high to allow excessive resources consumption.
1024 events consume something like 32KB which shouldn't be a big deal
and it should be good enough.
Signed-off-by: Michal Hocko
--
ood enough.
Reported-by: Tejun Heo
Signed-off-by: Michal Hocko
---
mm/memcontrol.c |8
1 file changed, 8 insertions(+)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index e4330cd..8247db3 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -5401,6 +5401,9 @@ static void mem_cgroup_
nts sounds
crazy).
Signed-off-by: Michal Hocko
---
mm/memcontrol.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 8247db3..233317a 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -273,6 +273,7 @@ struct
On Tue 06-08-13 12:15:09, Tejun Heo wrote:
> Hello, Michal.
>
> On Tue, Aug 06, 2013 at 05:58:04PM +0200, Michal Hocko wrote:
> > I am objecting to moving the generic part of that code into memcg. The
> > memcg part and the additional complexity (all the parsing and conditio
On Wed 07-08-13 08:43:21, Tejun Heo wrote:
> Hello, Michal.
>
> On Wed, Aug 07, 2013 at 02:18:36PM +0200, Michal Hocko wrote:
> > How is it specific to memcg? The fact only memcg uses the interface
> > doesn't imply it is memcg specific.
>
> I don't follo
On Wed 07-08-13 09:08:36, Tejun Heo wrote:
> Hello, Michal.
>
> On Wed, Aug 07, 2013 at 01:28:26PM +0200, Michal Hocko wrote:
> > There is no limit for the maximum number of oom_control events
> > registered per memcg. This might lead to an user triggered memory
> > dep
On Wed 07-08-13 09:22:10, Tejun Heo wrote:
> Hello,
>
> On Wed, Aug 07, 2013 at 01:28:25PM +0200, Michal Hocko wrote:
> > There is no limit for the maximum number of threshold events registered
> > per memcg. This might lead to an user triggered memory depletion if a
> &
On Wed 07-08-13 09:47:41, Tejun Heo wrote:
> Hello,
>
> On Wed, Aug 07, 2013 at 03:37:46PM +0200, Michal Hocko wrote:
> > > It isn't different from listening from epoll, for example.
> >
> > epoll limits the number of watchers, no?
>
> Not that I know of
On Wed 07-08-13 09:58:18, Tejun Heo wrote:
> Hello,
>
> On Wed, Aug 07, 2013 at 03:46:54PM +0200, Michal Hocko wrote:
> > OK, I have obviously misunderstood your concern mentioned in the other
> > email. Could you be more specific what is the DoS scenario which was
> >
On Wed 07-08-13 15:57:34, Michal Hocko wrote:
[...]
> Hmm, OK so you think that the fd limit is sufficient already?
Hmm, that would need to touch the code as well (the register callback
would need to make sure only one event is registered per cfile). But yes
this way would be better. I will s
On Wed 07-08-13 16:47:30, Michal Hocko wrote:
> On Wed 07-08-13 15:57:34, Michal Hocko wrote:
> [...]
> > Hmm, OK so you think that the fd limit is sufficient already?
>
> Hmm, that would need to touch the code as well (the register callback
> would need to make sure only on
n't strictly necessary, this shouldn't cause any
> noticeable difference.
>
> Signed-off-by: Tejun Heo
> Cc: Li Zefan
> Cc: Jens Axboe
> Cc: Vivek Goyal
> Cc: Matt Helsley
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Balbir Singh
> Cc: Aristeu
On Thu 08-08-13 01:05:13, Kirill A. Shutemov wrote:
> On Wed, Aug 07, 2013 at 04:37:27PM +0200, Michal Hocko wrote:
> > On Wed 07-08-13 09:58:18, Tejun Heo wrote:
> > > Hello,
> > >
> > > On Wed, Aug 07, 2013 at 03:46:54PM +0200, Michal Hocko wrote:
> > &
which synchronizes callers to the sysctl
handler.
Signed-off-by: Michal Hocko
---
kernel/watchdog.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 1241d8c..2d64c02 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -520,13 +5
fe
because perf_event_disable removes the event atomically before it clears
the per-cpu watchdog_ev so it cannot change under running handler feet.
Signed-off-by: Michal Hocko
---
kernel/watchdog.c | 32 +---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --gi
On Fri 19-07-13 12:10:48, Don Zickus wrote:
> On Fri, Jul 19, 2013 at 11:04:58AM +0200, Michal Hocko wrote:
> > proc_dowatchdog doesn't synchronize multiple callers which
> > might lead to confusion when two parallel callers might confuse
> > wat
and it introduces vmpressure_cleanup
which flushes the vmpressure work queue item item. It hooks into
mem_cgroup_css_offline after the memcg itself is cleaned up.
Reported-by: Tejun Heo
Signed-off-by: Michal Hocko
---
include/linux/vmpressure.h | 1 +
mm/memcontrol.c| 1 +
On Fri 19-07-13 12:08:52, Don Zickus wrote:
> On Fri, Jul 19, 2013 at 11:04:59AM +0200, Michal Hocko wrote:
> > watchdog_tresh controls how often nmi perf event counter checks per-cpu
> > hrtimer_interrupts counter and blows up if the counter hasn't changed
> > since the
because it is racy and it doesn't give us much anyway as schedule_work
handles this case already.
Brought-up-by: Tejun Heo
Signed-off-by: Michal Hocko
---
mm/vmpressure.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/vmpressure.c b/mm/vmpressure.c
index f4
There is nothing that can sleep inside critical sections protected by
this lock and those sections are really small so there doesn't make much
sense to use mutex for them. Change the log to a spinlock
Brought-up-by: Tejun Heo
Signed-off-by: Michal Hocko
---
include/linux/vmpressure.h
On Fri 19-07-13 14:05:30, Don Zickus wrote:
> On Fri, Jul 19, 2013 at 06:37:50PM +0200, Michal Hocko wrote:
> > On Fri 19-07-13 12:08:52, Don Zickus wrote:
> > > On Fri, Jul 19, 2013 at 11:04:59AM +0200, Michal Hocko wrote:
> > > > watchdog_tresh controls how often
will fire&adopt to the new sampling
period before a new nmi event triggers (when the treshold is decreased).
Changes since v1
- restart hrtimer to ensure that hrtimer doesn't mess new nmi as pointed
out by Don Zickus
Signed-off-by: Michal Hocko
---
ker
> #ifdef CONFIG_MEMORY_HOTREMOVE
> extern int unregister_memory_section(struct mem_section *);
> #endif
> --
> 1.7.4.1
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
>
On Mon 22-07-13 13:45:02, Michal Hocko wrote:
[...]
> @@ -486,7 +486,50 @@ static struct smp_hotplug_thread watchdog_threads = {
> .unpark = watchdog_enable,
> };
>
> -static int watchdog_enable_all_cpus(void)
> +static void restart_watchdog_
we cannot rely it will fire&adopt
to the new sampling period before a new nmi event triggers (when the
treshold is decreased).
Changes since v1
- restart hrtimer to ensure that hrtimer doesn't mess new nmi as pointed
out by Don Zickus
Signed-off-by: Michal Hocko
---
ker
On Mon 15-07-13 18:52:39, Joonsoo Kim wrote:
> We don't need to proceede the processing if we don't have any usable
> free huge page. So move this code up.
>
> Signed-off-by: Joonsoo Kim
Acked-by: Michal Hocko
after you add a note about hugetlb_lock which stabiliz
On Mon 15-07-13 18:52:40, Joonsoo Kim wrote:
> The name of the mutex written in comment is wrong.
> Fix it.
>
> Signed-off-by: Joonsoo Kim
Acked-by: Michal Hocko
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index d87f70b..d21a33a 100644
> --- a/mm/hugetlb.c
> +++
Better?
> Signed-off-by: Joonsoo Kim
Acked-by: Michal Hocko
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index d21a33a..0067cf4 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1144,29 +1144,25 @@ static struct page *alloc
On Mon 15-07-13 18:52:43, Joonsoo Kim wrote:
> If list is empty, list_for_each_entry_safe() doesn't do anything.
> So, this check is redundant. Remove it.
>
> Signed-off-by: Joonsoo Kim
Acked-by: Michal Hocko
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> ind
cpuset_mems_cookie = get_mems_allowed();
> @@ -573,9 +573,6 @@ retry_cpuset:
> if (unlikely(!put_mems_allowed(cpuset_mems_cookie) && !page))
> goto retry_cpuset;
> return page;
> -
> -err:
> - return NULL;
This doesn't give us anything IMO.
nodes_allowed);
> - continue;
> - }
> + } else {
> + for_each_node_mask_to_free(h, nr_nodes, node, nodes_allowed) {
> + if (h->surplus_huge_pages_n
ER STEAL PRIVATE WRITE: %c\n", p[0]);
> munmap(p, size);
>
> We can see that "AFTER STEAL PRIVATE WRITE: c", not "AFTER STEAL
> PRIVATE WRITE: s". If we turn off this optimization to a page
> in page cache, the problem is disappeared.
It would be
{
> + if (vma->vm_flags & VM_NORESERVE)
> + return 0;
> if (vma->vm_flags & VM_MAYSHARE)
> return 1;
> if (is_vma_resv_set(vma, HPAGE_RESV_OWNER))
> --
> 1.7.9.5
>
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
break;
> +
> + h->resv_huge_pages--;
> break;
> }
> }
> @@ -1135,7 +1153,7 @@ static struct page *alloc_huge_page(struct
> vm_area_struct *vma,
> return ERR_PTR(-ENOSPC);
&
On Fri 19-07-13 11:17:44, Andrew Morton wrote:
[...]
> A git tree which contains the memory management portion of this tree is
> maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> by Michal Hocko. It contains the patches which are between the
> "#NEXT
this tree is
> > > > >maintained at
> > > > >git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> > > > >by Michal Hocko. It contains the patches which are between the
> > > > >"#NEXT_PATCHES_START mm" and &quo
ge_pmd_share is serialized correctly now which in turn means that the
success of the sharing will be higher as the racing tasks see the pud
and pmd populated together.
"
Besides that I fail to see how moving pmd_alloc down changes anything.
Even if pmd_alloc triggered reclaim then we
On Tue 23-07-13 09:53:34, Don Zickus wrote:
> On Mon, Jul 22, 2013 at 04:32:46PM +0200, Michal Hocko wrote:
> > The nmi one is disabled and then reinitialized from scratch. This
> > has an unpleasant side effect that the allocation of the new event might
> > fail theoretical
On Tue 23-07-13 10:44:08, Don Zickus wrote:
> On Tue, Jul 23, 2013 at 04:07:29PM +0200, Michal Hocko wrote:
> > On Tue 23-07-13 09:53:34, Don Zickus wrote:
> > > On Mon, Jul 22, 2013 at 04:32:46PM +0200, Michal Hocko wrote:
> > > > The nmi one is disabled and then re
On Mon 15-07-13 14:49:40, Vivek Goyal wrote:
> On Sun, Jun 30, 2013 at 08:38:38PM +0200, Michal Hocko wrote:
> > On Fri 28-06-13 14:01:55, Vivek Goyal wrote:
> > > On Fri, Jun 28, 2013 at 05:05:13PM +0200, Michal Hocko wrote:
> > [...]
> > > > OK, so libcgrou
On Tue 23-07-13 14:52:36, KY Srinivasan wrote:
>
>
> > -Original Message-
> > From: Michal Hocko [mailto:mho...@suse.cz]
> > Sent: Monday, July 22, 2013 8:37 AM
> > To: KY Srinivasan
> > Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
}
> if (!ret)
> strcpy(zcache_comp_name, "lzo");
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at
On Wed 24-07-13 12:02:35, Michal Hocko wrote:
> I have posted a similar fix quite some time ago and I guess Greg should
> already have it.
For reference https://lkml.org/lkml/2013/6/26/410
> Greg?
>
> On Fri 19-07-13 16:46:41, Piotr Sarna wrote:
> > Commit 835f2f5 (&qu
On Wed 24-07-13 12:32:32, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Wednesday, July 24, 2013 12:04:41 PM Michal Hocko wrote:
> > On Wed 24-07-13 12:02:35, Michal Hocko wrote:
> > > I have posted a similar fix quite some time ago and I guess Greg should
> >
Li Zefan
Reviewed-by: Michal Hocko
> ---
> include/linux/cgroup.h | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
> index 2bd052d..8c107e9 100644
> --- a/include/linux/cgroup.h
> +++ b/inclu
On Wed 24-07-13 17:59:12, Li Zefan wrote:
> This enables us to lookup a cgroup by its id.
>
> Signed-off-by: Li Zefan
Reviewed-by: Michal Hocko
One nit/question bellow
[...]
> @@ -4268,15 +4271,19 @@ static long cgroup_create(struct cgroup *parent,
> struct dentry *dentry,
&g
On Wed 24-07-13 18:00:39, Li Zefan wrote:
> This will be used as a replacement for css_lookup().
>
> There's a difference with cgroup id and css id. cgroup id starts with 0,
> while css id starts with 1.
>
> Signed-off-by: Li Zefan
Reviewed-by: Michal Hocko
Typo fix be
is not called from any hot path.
Acked-by: Michal Hocko
> ---
> mm/memcontrol.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index d12ca6f..626c426 100644
> --- a/mm/memcontrol.c
> +++ b/mm/mem
On Wed 24-07-13 18:01:53, Li Zefan wrote:
> Use cgroup id instead of css id. This is a preparation to kill css id.
>
> Note, as memcg treats 0 as an invalid id, while cgroup id starts with 0,
> we define memcg_id == cgroup_id + 1.
>
> Signed-off-by: Li Zefan
Acked-by: Michal
On Wed 24-07-13 18:02:19, Li Zefan wrote:
> memcg requires the cgroup id to be smaller than 65536.
>
> Signed-off-by: Li Zefan
Acked-by: Michal Hocko
One suggestion bellow
> ---
> mm/memcontrol.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --gi
On Wed 24-07-13 18:03:36, Li Zefan wrote:
> The only user of css_id was memcg, and it has been convered to use
> cgroup->id, so kill css_id.
>
> Signed-off-by: Li Zefan
Nice
Reviewed-by: Michal Hocko
> ---
> include/linux/cgroup.h | 37
> kern
On Wed 24-07-13 18:03:03, Li Zefan wrote:
> Now memcg uses cgroup id instead of css id. Update some comments and
> set mem_cgroup_subsys->use_id to 0.
>
> Signed-off-by: Li Zefan
Acked-by: Michal Hocko
> ---
> mm/memcontrol.c | 23 ---
> 1 fi
gt; include/linux/cgroup.h | 49 ++---
> kernel/cgroup.c| 308
> ---
> mm/memcontrol.c | 59 ++-
> 3 files changed, 90 insertions(+), 326 deletions(-)
--
Michal Hocko
SUSE Labs
--
To unsubscribe from
"goto out" directive inside the "if (!ret)" statement
> 2. In case that crypto_has_comp() returned 0, change the value of ret
>to non-zero before "goto out" to indicate an error.
>
> This patch replaces an earlier one from Michal Hocko (based on rep
On Wed 24-07-13 12:14:07, Tejun Heo wrote:
> On Wed, Jul 24, 2013 at 04:32:14PM +0200, Michal Hocko wrote:
> > On Wed 24-07-13 17:58:44, Li Zefan wrote:
> > > This patchset converts memcg to use cgroup->id, and then we can remove
> > > cgroup css_id.
> > &
On Thu 25-07-13 08:59:15, Li Zefan wrote:
> On 2013/7/24 22:32, Michal Hocko wrote:
> > On Wed 24-07-13 17:58:44, Li Zefan wrote:
> >> This patchset converts memcg to use cgroup->id, and then we can remove
> >> cgroup css_id.
> >>
> >> As we'v
the memory after having succeeded in hot adding
> > the
> > memory.
>
> I think we should hold off on this patch and other like it until we've
> been sufficiently able to explain how (b) happens.
Agreed.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from thi
On Thu 25-07-13 09:53:09, Li Zefan wrote:
> vfs guarantees the cgroup won't be destroyed, so it's redundant
> to get a css reference.
>
> Signed-off-by: Li Zefan
Acked-by: Michal Hocko
Thanks!
> ---
> mm/memcontrol.c | 7 +--
> 1 file changed, 1 inserti
On Wed 24-07-13 11:44:28, Minchan Kim wrote:
> On Tue, Jul 23, 2013 at 04:01:20PM +0200, Michal Hocko wrote:
> > On Fri 19-07-13 09:13:03, Minchan Kim wrote:
> > > On Thu, Jul 18, 2013 at 11:12:24PM +0530, Aneesh Kumar K.V wrote:
> > [...]
> > > > diff
hould help developers
: who are chasing down reclaim-related bugs.
[mho...@suse.cz: refreshed to current -mm tree]
[a...@linux-foundation.org: checkpatch fixes]
Signed-off-by: Dave Hansen
Signed-off-by: Michal Hocko
Acked-by: KOSAKI Motohiro
Acked-by: KAMEZAWA Hiroyuki
---
Documentat
we cannot rely it will fire&adopt
to the new sampling period before a new nmi event triggers (when the
treshold is decreased).
Changes since v1
- restart hrtimer to ensure that hrtimer doesn't mess new nmi as pointed
out by Don Zickus
Signed-off-by: Michal Hocko
Acked-by: Don
which synchronizes callers to the sysctl
handler.
Signed-off-by: Michal Hocko
---
kernel/watchdog.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 1241d8c..2d64c02 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -520,13 +5
eric OOM killer (609838c
> "mm: invoke oom-killer from remaining unconverted page fault
> handlers"), which already provides init protection, the arch-specific
> leftovers can be removed.
>
> Signed-off-by: Johannes Weiner
Looks good to me
Reviewed-by: Michal Ho
ures already do this, fix up the remaining few.
>
> Signed-off-by: Johannes Weiner
I didn't go over all architectures to check whether something slipped
through but the converted ones look OK to me.
Reviewed-by: Michal Hocko
> ---
> arch/arm/mm/fault.c | 14 +++
chs should be
CCed
Reviewed-by: Michal Hocko
> ---
> arch/alpha/mm/fault.c | 7 ---
> arch/arc/mm/fault.c| 6 --
> arch/arm/mm/fault.c| 9 ++---
> arch/arm64/mm/fault.c | 9 ++---
> arch/avr32/mm/fault.c | 2 ++
> arch/cris/
n that reads suprisingly
> similar to ARM's.
>
> Signed-off-by: Johannes Weiner
Reviewed-by: Michal Hocko
> ---
> arch/x86/mm/fault.c | 35 +--
> 1 file changed, 17 insertions(+), 18 deletions(-)
>
> diff --git a/arch/x86/mm/fault.
y_oom(current, true) == true);
> +
> + ret = __handle_mm_fault(mm, vma, address, flags);
> +
> + if (flags & FAULT_FLAG_USER)
> + WARN_ON(mem_cgroup_xchg_may_oom(current, false) == false);
Ohh, I see why you used !new in mem_cgroup_xchg_may_oom for !MEMCG case
abov
ing the killer. In addition to the wakeup implied in
> the kill signal delivery, only uncharges and limit increases, things
> that actually change the memory situation, should poke the waitqueue.
>
> Reported-by: Reported-by: azurIt
> Debugged-by: Michal Hocko
> Signed-off-by: J
zone
as pointed by Johannes
Signed-off-by: Michal Hocko
Reviewed-by: Glauber Costa
Reviewed-by: Tejun Heo
---
include/linux/memcontrol.h | 10 +--
mm/memcontrol.c| 163 ++---
mm/vmscan.c| 62 +
3 files ch
zation is necessary.
Signed-off-by: Michal Hocko
---
mm/memcontrol.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 8629ca6..b5febaf 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -865,9 +865,15 @@ static void mem_cgroup_update_soft_lim
ast give a chance to start the walk without a big risk of
reclaim latencies.
Signed-off-by: Michal Hocko
---
mm/vmscan.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index b45ff5b..6134708 100644
--- a/mm/vmscan.c
+++ b/m
esting results for bunch of cgroups with both stream IO and kbuild
loads can be found in "memcg: track children in soft limit excess to
improve soft limit".
The series has seen quite some testing and I guess it is in the state to
be merged into mmotm and hopefully get into 3.12. I wou
d but the tree walk continues down the tree or
the whole subtree of the current group is skipped.
Signed-off-by: Michal Hocko
---
include/linux/memcontrol.h | 48 +
mm/memcontrol.c| 77 --
mm/vmscan.c
701 - 800 of 11648 matches
Mail list logo
