Re: [PATCH v2] IB: make INFINIBAND_ADDR_TRANS configurable

On Sat, Apr 14, 2018 at 8:13 AM Dennis Dalessandro < dennis.dalessan...@intel.com> wrote: > On 4/13/2018 1:27 PM, Greg Thelen wrote: > > Allow INFINIBAND without INFINIBAND_ADDR_TRANS. > > > > Signed-off-by: Greg Thelen <gthe...@google.com> > > Cc: Tarick B

Re: [PATCH v2] IB: make INFINIBAND_ADDR_TRANS configurable

On Sat, Apr 14, 2018 at 8:13 AM Dennis Dalessandro < dennis.dalessan...@intel.com> wrote: > On 4/13/2018 1:27 PM, Greg Thelen wrote: > > Allow INFINIBAND without INFINIBAND_ADDR_TRANS. > > > > Signed-off-by: Greg Thelen > >

[PATCH v2] IB: make INFINIBAND_ADDR_TRANS configurable

Allow INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by: Greg Thelen <gthe...@google.com> Cc: Tarick Bedeir <tar...@google.com> Change-Id: I6fbbf8a432e467710fa65e4904b7d61880b914e5 --- drivers/infiniband/Kconfig | 5 - 1 file changed, 4 insertions(+), 1 deletion(-)

[PATCH v2] IB: make INFINIBAND_ADDR_TRANS configurable

Allow INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by: Greg Thelen Cc: Tarick Bedeir Change-Id: I6fbbf8a432e467710fa65e4904b7d61880b914e5 --- drivers/infiniband/Kconfig | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/infiniband/Kconfig b/drivers

[PATCH] IB: make INFINIBAND_ADDR_TRANS configurable

Allow INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by: Greg Thelen <gthe...@google.com> Cc: Tarick Bedeir <tar...@google.com> --- drivers/infiniband/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/Kconfig b/drivers/infiniband/K

[PATCH] IB: make INFINIBAND_ADDR_TRANS configurable

Allow INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by: Greg Thelen Cc: Tarick Bedeir --- drivers/infiniband/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/Kconfig b/drivers/infiniband/Kconfig index ee270e065ba9..f20a3977087c 100644

Re: [PATCH for-4.4] writeback: safer lock nesting

On Wed, Apr 11, 2018 at 1:45 AM Greg Thelen <gthe...@google.com> wrote: > lock_page_memcg()/unlock_page_memcg() use spin_lock_irqsave/restore() if > the page's memcg is undergoing move accounting, which occurs when a > process leaves its memcg for a n

Re: [PATCH for-4.4] writeback: safer lock nesting

On Wed, Apr 11, 2018 at 1:45 AM Greg Thelen wrote: > lock_page_memcg()/unlock_page_memcg() use spin_lock_irqsave/restore() if > the page's memcg is undergoing move accounting, which occurs when a > process leaves its memcg for a new one that has > memory.move_charge_at_i

[PATCH v4] writeback: safer lock nesting

patch see "[PATCH for-4.4] writeback: safer lock nesting" https://lkml.org/lkml/2018/4/11/146 Fixes: 682aa8e1a6a1 ("writeback: implement unlocked_inode_to_wb transaction and use it for stat updates") Cc: sta...@vger.kernel.org # v4.2+ Reported-by: Wang Long <wanglon...@meitua

[PATCH v4] writeback: safer lock nesting

patch see "[PATCH for-4.4] writeback: safer lock nesting" https://lkml.org/lkml/2018/4/11/146 Fixes: 682aa8e1a6a1 ("writeback: implement unlocked_inode_to_wb transaction and use it for stat updates") Cc: sta...@vger.kernel.org # v4.2+ Reported-by: Wang Long Signed-off-by:

[PATCH for-4.4] writeback: safer lock nesting

be able to cherry pick the upstream "writeback: safer lock nesting" patch. ] Fixes: 682aa8e1a6a1 ("writeback: implement unlocked_inode_to_wb transaction and use it for stat updates") Cc: sta...@vger.kernel.org # v4.2+ Reported-by: Wang Long <wanglon...@meituan.com> S

[PATCH for-4.4] writeback: safer lock nesting

be able to cherry pick the upstream "writeback: safer lock nesting" patch. ] Fixes: 682aa8e1a6a1 ("writeback: implement unlocked_inode_to_wb transaction and use it for stat updates") Cc: sta...@vger.kernel.org # v4.2+ Reported-by: Wang Long Signed-off-by: Greg Thelen

Re: [PATCH] writeback: safer lock nesting

On Tue, Apr 10, 2018 at 7:44 PM Wang Long wrote: > > Hi, > > > > [This is an automated email] > > > > This commit has been processed by the -stable helper bot and determined > > to be a high probability candidate for -stable trees. (score: 44.5575) > > > > The bot has

Re: [PATCH] writeback: safer lock nesting

On Tue, Apr 10, 2018 at 7:44 PM Wang Long wrote: > > Hi, > > > > [This is an automated email] > > > > This commit has been processed by the -stable helper bot and determined > > to be a high probability candidate for -stable trees. (score: 44.5575) > > > > The bot has tested the following trees:

Re: [PATCH v3] writeback: safer lock nesting

On Tue, Apr 10, 2018 at 1:38 PM Andrew Morton <a...@linux-foundation.org> wrote: > On Mon, 9 Apr 2018 17:59:08 -0700 Greg Thelen <gthe...@google.com> wrote: > > lock_page_memcg()/unlock_page_memcg() use spin_lock_irqsave/restore() if > > the page's memcg is underg

Re: [PATCH v3] writeback: safer lock nesting

On Tue, Apr 10, 2018 at 1:38 PM Andrew Morton wrote: > On Mon, 9 Apr 2018 17:59:08 -0700 Greg Thelen wrote: > > lock_page_memcg()/unlock_page_memcg() use spin_lock_irqsave/restore() if > > the page's memcg is undergoing move accounting, which occurs when a > > pro

Re: [PATCH v3] writeback: safer lock nesting

On Tue, Apr 10, 2018 at 1:15 AM Wang Long wrote: > > lock_page_memcg()/unlock_page_memcg() use spin_lock_irqsave/restore() if > > the page's memcg is undergoing move accounting, which occurs when a > > process leaves its memcg for a new one that has > >

Re: [PATCH v3] writeback: safer lock nesting

On Tue, Apr 10, 2018 at 1:15 AM Wang Long wrote: > > lock_page_memcg()/unlock_page_memcg() use spin_lock_irqsave/restore() if > > the page's memcg is undergoing move accounting, which occurs when a > > process leaves its memcg for a new one that has > > memory.move_charge_at_immigrate set. > > >

[PATCH v3] writeback: safer lock nesting

table if there's any reason to modify the kernel. I suggest we should to prevent future surprises. Reported-by: Wang Long <wanglon...@meituan.com> Signed-off-by: Greg Thelen <gthe...@google.com> Change-Id: Ibb773e8045852978f6207074491d262f1b3fb613 --- Changelog since v2: - explicit

[PATCH v3] writeback: safer lock nesting

table if there's any reason to modify the kernel. I suggest we should to prevent future surprises. Reported-by: Wang Long Signed-off-by: Greg Thelen Change-Id: Ibb773e8045852978f6207074491d262f1b3fb613 --- Changelog since v2: - explicitly initialize wb_lock_cookie to silence compiler warnings.

[PATCH v2] writeback: safer lock nesting

table if there's any reason to modify the kernel. I suggest we should to prevent future surprises. Reported-by: Wang Long <wanglon...@meituan.com> Signed-off-by: Greg Thelen <gthe...@google.com> --- Changelog since v1: - add wb_lock_cookie to record lock context. fs/fs-writeback.c

[PATCH v2] writeback: safer lock nesting

table if there's any reason to modify the kernel. I suggest we should to prevent future surprises. Reported-by: Wang Long Signed-off-by: Greg Thelen --- Changelog since v1: - add wb_lock_cookie to record lock context. fs/fs-writeback.c| 7 --- include/linux/backing-dev-defs.

Re: [PATCH] writeback: safer lock nesting

On Fri, Apr 6, 2018 at 1:07 AM Michal Hocko <mho...@kernel.org> wrote: > On Fri 06-04-18 01:03:24, Greg Thelen wrote: > [...] > > diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c > > index d4d04fee568a..d51bae5a53e2 100644 > > --- a/fs/fs-writeback.c > > ++

Re: [PATCH] writeback: safer lock nesting

On Fri, Apr 6, 2018 at 1:07 AM Michal Hocko wrote: > On Fri 06-04-18 01:03:24, Greg Thelen wrote: > [...] > > diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c > > index d4d04fee568a..d51bae5a53e2 100644 > > --- a/fs/fs-writeback.c > > +++ b/fs/fs-writeback.c

[PATCH] writeback: safer lock nesting

table if there's any reason to modify the kernel. I suggest we should to prevent future surprises. Reported-by: Wang Long <wanglon...@meituan.com> Signed-off-by: Greg Thelen <gthe...@google.com> --- fs/fs-writeback.c | 5 +++-- include/linux/backing-dev.h | 18 -

[PATCH] writeback: safer lock nesting

table if there's any reason to modify the kernel. I suggest we should to prevent future surprises. Reported-by: Wang Long Signed-off-by: Greg Thelen --- fs/fs-writeback.c | 5 +++-- include/linux/backing-dev.h | 18 -- mm/page-writeback.c | 15 +-- 3 f

Re: [RFC] Is it correctly that the usage for spin_{lock|unlock}_irq in clear_page_dirty_for_io

On Tue, Apr 3, 2018 at 5:03 AM Michal Hocko wrote: > On Mon 02-04-18 19:50:50, Wang Long wrote: > > > > Hi, Johannes Weiner and Tejun Heo > > > > I use linux-4.4.y to test the new cgroup controller io and the current > > stable kernel linux-4.4.y has the follow logic > > > >

Re: [RFC] Is it correctly that the usage for spin_{lock|unlock}_irq in clear_page_dirty_for_io

On Tue, Apr 3, 2018 at 5:03 AM Michal Hocko wrote: > On Mon 02-04-18 19:50:50, Wang Long wrote: > > > > Hi, Johannes Weiner and Tejun Heo > > > > I use linux-4.4.y to test the new cgroup controller io and the current > > stable kernel linux-4.4.y has the follow logic > > > > > > int

Re: [PATCH] RDMA/ucma: reject AF_IB ip multicast requests

On Thu, Mar 29, 2018 at 9:24 PM, Greg Thelen <gthe...@google.com> wrote: > syzbot discovered that ucma_join_ip_multicast() mishandles AF_IB request > addresses. If an RDMA_USER_CM_CMD_JOIN_IP_MCAST request has > cmd.addr.sa_family=AF_IB then ucma_join_ip_multicast() reads beyond t

Re: [PATCH] RDMA/ucma: reject AF_IB ip multicast requests

On Thu, Mar 29, 2018 at 9:24 PM, Greg Thelen wrote: > syzbot discovered that ucma_join_ip_multicast() mishandles AF_IB request > addresses. If an RDMA_USER_CM_CMD_JOIN_IP_MCAST request has > cmd.addr.sa_family=AF_IB then ucma_join_ip_multicast() reads beyond the > end of its cmd.addr

[PATCH] RDMA/ucma: reject AF_IB ip multicast requests

. RDMA_USER_CM_CMD_JOIN_MCAST is interface for AF_IB multicast. And add a buffer length safety check. Fixes: 5bc2b7b397b0 ("RDMA/ucma: Allow user space to specify AF_IB when joining multicast") Signed-off-by: Greg Thelen <gthe...@google.com> --- drivers/infiniband/core/ucma.c | 10 +- 1

[PATCH] RDMA/ucma: reject AF_IB ip multicast requests

. RDMA_USER_CM_CMD_JOIN_MCAST is interface for AF_IB multicast. And add a buffer length safety check. Fixes: 5bc2b7b397b0 ("RDMA/ucma: Allow user space to specify AF_IB when joining multicast") Signed-off-by: Greg Thelen --- drivers/infiniband/core/ucma.c | 10 +- 1 file changed, 9 insert

Re: [PATCH v2] mm, shrinker: make shrinker_list lockless

(off list) Shakeel Butt wrote: > In our production, we have observed that the job loader gets stuck for > 10s of seconds while doing mount operation. It turns out that it was > stuck in register_shrinker() and some unrelated job was under memory > pressure and spending time

Re: [PATCH v2] mm, shrinker: make shrinker_list lockless

(off list) Shakeel Butt wrote: > In our production, we have observed that the job loader gets stuck for > 10s of seconds while doing mount operation. It turns out that it was > stuck in register_shrinker() and some unrelated job was under memory > pressure and spending time in shrink_slab().

Re: [PATCH] fs, mm: account filp and names caches to kmemcg

Michal Hocko wrote: > Greg Thelen wrote: > > So a force charge fallback might be a needed even with oom killer successful > > invocations. Or we'll need to teach out_of_memory() to return three values > > (e.g. NO_VICTIM, NEW_VICTIM, PENDING_VICTIM) and try_charge() can l

Re: [PATCH] fs, mm: account filp and names caches to kmemcg

Michal Hocko wrote: > Greg Thelen wrote: > > So a force charge fallback might be a needed even with oom killer successful > > invocations. Or we'll need to teach out_of_memory() to return three values > > (e.g. NO_VICTIM, NEW_VICTIM, PENDING_VICTIM) and try_charge() can l

Re: [PATCH] fs, mm: account filp and names caches to kmemcg

Johannes Weiner wrote: > On Wed, Oct 25, 2017 at 09:00:57PM +0200, Michal Hocko wrote: >> On Wed 25-10-17 14:11:06, Johannes Weiner wrote: >> > "Safe" is a vague term, and it doesn't make much sense to me in this >> > situation. The OOM behavior should be predictable and

Re: [PATCH] fs, mm: account filp and names caches to kmemcg

Johannes Weiner wrote: > On Wed, Oct 25, 2017 at 09:00:57PM +0200, Michal Hocko wrote: >> On Wed 25-10-17 14:11:06, Johannes Weiner wrote: >> > "Safe" is a vague term, and it doesn't make much sense to me in this >> > situation. The OOM behavior should be predictable and consistent. >> > >> >

Re: [PATCH] fs, mm: account filp and names caches to kmemcg

Michal Hocko wrote: > On Tue 24-10-17 14:58:54, Johannes Weiner wrote: >> On Tue, Oct 24, 2017 at 07:55:58PM +0200, Michal Hocko wrote: >> > On Tue 24-10-17 13:23:30, Johannes Weiner wrote: >> > > On Tue, Oct 24, 2017 at 06:22:13PM +0200, Michal Hocko wrote: >> > [...] >> > >

Re: [PATCH] fs, mm: account filp and names caches to kmemcg

Michal Hocko wrote: > On Tue 24-10-17 14:58:54, Johannes Weiner wrote: >> On Tue, Oct 24, 2017 at 07:55:58PM +0200, Michal Hocko wrote: >> > On Tue 24-10-17 13:23:30, Johannes Weiner wrote: >> > > On Tue, Oct 24, 2017 at 06:22:13PM +0200, Michal Hocko wrote: >> > [...] >> > > > What would

Re: [PATCH] fs, mm: account filp and names caches to kmemcg

Johannes Weiner wrote: > On Tue, Oct 10, 2017 at 04:24:34PM +0200, Michal Hocko wrote: >> On Tue 10-10-17 10:17:33, Johannes Weiner wrote: >> > On Tue, Oct 10, 2017 at 11:14:30AM +0200, Michal Hocko wrote: >> > > On Mon 09-10-17 16:26:13, Johannes Weiner wrote: >> > > > It's

Re: [PATCH] fs, mm: account filp and names caches to kmemcg

Johannes Weiner wrote: > On Tue, Oct 10, 2017 at 04:24:34PM +0200, Michal Hocko wrote: >> On Tue 10-10-17 10:17:33, Johannes Weiner wrote: >> > On Tue, Oct 10, 2017 at 11:14:30AM +0200, Michal Hocko wrote: >> > > On Mon 09-10-17 16:26:13, Johannes Weiner wrote: >> > > > It's consistent in the

Re: [PATCH] fs, mm: account filp and names caches to kmemcg

Michal Hocko wrote: > On Fri 06-10-17 12:33:03, Shakeel Butt wrote: >> >> names_cachep = kmem_cache_create("names_cache", PATH_MAX, 0, >> >> - SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL); >> >> +

Re: [PATCH] fs, mm: account filp and names caches to kmemcg

Michal Hocko wrote: > On Fri 06-10-17 12:33:03, Shakeel Butt wrote: >> >> names_cachep = kmem_cache_create("names_cache", PATH_MAX, 0, >> >> - SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL); >> >> + SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_ACCOUNT, NULL); >> > >> >

[PATCH] block: tolerate tracing of NULL bio

gendisk pointer and partitions index") Signed-off-by: Greg Thelen <gthe...@google.com> --- include/trace/events/block.h | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/include/trace/events/block.h b/include/trace/events/block.h index f815aaaef755..1fd7ff1a46f7 100644

[PATCH] block: tolerate tracing of NULL bio

gendisk pointer and partitions index") Signed-off-by: Greg Thelen --- include/trace/events/block.h | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/include/trace/events/block.h b/include/trace/events/block.h index f815aaaef755..1fd7ff1a46f7 100644 --- a/include/trace/e

Re: [PATCH] net/mlx4: suppress 'may be used uninitialized' warning

Leon Romanovsky <l...@kernel.org> wrote: > [ Unknown signature status ] > On Mon, Apr 17, 2017 at 11:21:35PM -0700, Greg Thelen wrote: >> gcc 4.8.4 complains that mlx4_SW2HW_MPT_wrapper() uses an uninitialized >> 'mpt' variable: >> drivers/net/ethernet/me

Re: [PATCH] net/mlx4: suppress 'may be used uninitialized' warning

Leon Romanovsky wrote: > [ Unknown signature status ] > On Mon, Apr 17, 2017 at 11:21:35PM -0700, Greg Thelen wrote: >> gcc 4.8.4 complains that mlx4_SW2HW_MPT_wrapper() uses an uninitialized >> 'mpt' variable: >> drivers/net/ethernet/mellanox/mlx4/resourc

[PATCH] net/mlx4: suppress 'may be used uninitialized' warning

in this function [-Wmaybe-uninitialized] mpt->mtt = mtt; I think this warning is a false complaint. mpt is only used when mr_res_start_move_to() return zero, and in all such cases it initializes mpt. But apparently gcc cannot see that. Initialize mpt to avoid the warning. Signed-off-by: G

[PATCH] net/mlx4: suppress 'may be used uninitialized' warning

in this function [-Wmaybe-uninitialized] mpt->mtt = mtt; I think this warning is a false complaint. mpt is only used when mr_res_start_move_to() return zero, and in all such cases it initializes mpt. But apparently gcc cannot see that. Initialize mpt to avoid the warning. Signed-off-by: G

[PATCH] slab: avoid IPIs when creating kmem caches

quot;cgroup.procs") for i in range(n): os.rmdir(str(i)) patched: 1 loops: 1069 => 1170 (+101 ipis) unpatched: 1 loops: 1192 => 48933 (+47741 ipis) Signed-off-by: Greg Thelen <gthe...@google.com> --- mm/slab.c | 7 ++- 1 file changed, 6 insertions(

[PATCH] slab: avoid IPIs when creating kmem caches

quot;cgroup.procs") for i in range(n): os.rmdir(str(i)) patched: 1 loops: 1069 => 1170 (+101 ipis) unpatched: 1 loops: 1192 => 48933 (+47741 ipis) Signed-off-by: Greg Thelen --- mm/slab.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) d

[PATCH 2/2] kasan: add memcg kmem_cache test

ccounted object [ 124.456789] kmem_cache_destroy test_cache: Slab cache still has objects Kernels with fix [1] don't have the "Slab cache still has objects" warning or the underlying leak. The new test runs and passes in the default (root) memcg, though in the root memcg it won't uncover the pro

[PATCH 2/2] kasan: add memcg kmem_cache test

ccounted object [ 124.456789] kmem_cache_destroy test_cache: Slab cache still has objects Kernels with fix [1] don't have the "Slab cache still has objects" warning or the underlying leak. The new test runs and passes in the default (root) memcg, though in the root memcg it won't uncover the pro

[PATCH 1/2] kasan: drain quarantine of memcg slab objects

(). This leak only affects destroyed SLAB_ACCOUNT kmem caches when kasan is enabled. So I don't think it's worth patching stable kernels. Signed-off-by: Greg Thelen <gthe...@google.com> --- include/linux/kasan.h | 4 ++-- mm/kasan/kasan.c | 2 +- mm/kasan/quarantine.c | 1 + mm/slab_common

[PATCH 1/2] kasan: drain quarantine of memcg slab objects

(). This leak only affects destroyed SLAB_ACCOUNT kmem caches when kasan is enabled. So I don't think it's worth patching stable kernels. Signed-off-by: Greg Thelen --- include/linux/kasan.h | 4 ++-- mm/kasan/kasan.c | 2 +- mm/kasan/quarantine.c | 1 + mm/slab_common.c | 4 +++-

[PATCH] memcg: fix stale mem_cgroup_force_empty() comment

commit f61c42a7d911 ("memcg: remove tasks/children test from mem_cgroup_force_empty()") removed memory reparenting from the function. Fix the function's comment. Signed-off-by: Greg Thelen <gthe...@google.com> --- mm/memcontrol.c | 3 +-- 1 file changed, 1 insertion(+), 2 de

[PATCH] memcg: fix stale mem_cgroup_force_empty() comment

commit f61c42a7d911 ("memcg: remove tasks/children test from mem_cgroup_force_empty()") removed memory reparenting from the function. Fix the function's comment. Signed-off-by: Greg Thelen --- mm/memcontrol.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/mm/me

Re: [GIT PULL] ext4 bug fixes for 4.6

Theodore Ts'o wrote: > The following changes since commit 243d50678583100855862bc084b8b307eea67f68: > > Merge branch 'overlayfs-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs (2016-03-22 > 13:11:15 -0700) > n> are available in the git repository at: > >

Re: [GIT PULL] ext4 bug fixes for 4.6

Theodore Ts'o wrote: > The following changes since commit 243d50678583100855862bc084b8b307eea67f68: > > Merge branch 'overlayfs-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs (2016-03-22 > 13:11:15 -0700) > n> are available in the git repository at: > >

Re: [PATCH 1/5] mm: uncharge kmem pages from generic free_page path

Vladimir Davydov wrote: > Currently, to charge a page to kmemcg one should use alloc_kmem_pages > helper. When the page is not needed anymore it must be freed with > free_kmem_pages helper, which will uncharge the page before freeing it. > Such a design is acceptable for thread info pages and

Re: [PATCH 1/5] mm: uncharge kmem pages from generic free_page path

Vladimir Davydov wrote: > Currently, to charge a page to kmemcg one should use alloc_kmem_pages > helper. When the page is not needed anymore it must be freed with > free_kmem_pages helper, which will uncharge the page before freeing it. > Such a design is acceptable for thread info pages and

Re: [PATCH] memcg: make mem_cgroup_read_stat() unsigned

Michal Hocko wrote: > On Tue 22-09-15 15:16:32, Greg Thelen wrote: >> mem_cgroup_read_stat() returns a page count by summing per cpu page >> counters. The summing is racy wrt. updates, so a transient negative sum >> is possible. Callers don't want negative values: >

[PATCH] fs, seqfile: always allow oom killer

but larger files use the oom killer to avoid ENOMEM. Memory overcommit requires use of the oom killer to select a victim regardless of file size. Enable oom killer for small seq_buf_alloc() allocations. Signed-off-by: David Rientjes Signed-off-by: Greg Thelen --- fs/seq_file.c | 11 -

Re: [PATCH] memcg: make mem_cgroup_read_stat() unsigned

Michal Hocko wrote: > On Tue 22-09-15 15:16:32, Greg Thelen wrote: >> mem_cgroup_read_stat() returns a page count by summing per cpu page >> counters. The summing is racy wrt. updates, so a transient negative sum >> is possible. Callers don't want negative values: >

[PATCH] fs, seqfile: always allow oom killer

but larger files use the oom killer to avoid ENOMEM. Memory overcommit requires use of the oom killer to select a victim regardless of file size. Enable oom killer for small seq_buf_alloc() allocations. Signed-off-by: David Rientjes <rient...@google.com> Signed-off-by: Greg Thelen <gthe...@

Re: [PATCH] memcg: make mem_cgroup_read_stat() unsigned

Andrew Morton wrote: > On Tue, 22 Sep 2015 17:42:13 -0700 Greg Thelen wrote: > >> Andrew Morton wrote: >> >> > On Tue, 22 Sep 2015 15:16:32 -0700 Greg Thelen wrote: >> > >> >> mem_cgroup_read_stat() returns a page count by summing per cpu page &

Re: [PATCH] memcg: make mem_cgroup_read_stat() unsigned

Andrew Morton wrote: > On Tue, 22 Sep 2015 17:42:13 -0700 Greg Thelen <gthe...@google.com> wrote: > >> Andrew Morton wrote: >> >> > On Tue, 22 Sep 2015 15:16:32 -0700 Greg Thelen <gthe...@google.com> wrote: >> > >> >> mem_cgr

[PATCH] memcg: remove pcp_counter_lock

Commit 733a572e66d2 ("memcg: make mem_cgroup_read_{stat|event}() iterate possible cpus instead of online") removed the last use of the per memcg pcp_counter_lock but forgot to remove the variable. Kill the vestigial variable. Signed-off-by: Greg Thelen --- include/linux/memcontrol.h

Re: [PATCH] memcg: make mem_cgroup_read_stat() unsigned

Andrew Morton wrote: > On Tue, 22 Sep 2015 15:16:32 -0700 Greg Thelen wrote: > >> mem_cgroup_read_stat() returns a page count by summing per cpu page >> counters. The summing is racy wrt. updates, so a transient negative sum >> is possible. Callers do

[PATCH] memcg: make mem_cgroup_read_stat() unsigned

shouldn't show confusing negative usage. - tree_usage() already avoids negatives. Avoid returning negative page counts from mem_cgroup_read_stat() and convert it to unsigned. Signed-off-by: Greg Thelen --- mm/memcontrol.c | 30 ++ 1 file changed, 18 insertions(+), 12

Re: [PATCH] memcg: make mem_cgroup_read_stat() unsigned

Andrew Morton wrote: > On Tue, 22 Sep 2015 15:16:32 -0700 Greg Thelen <gthe...@google.com> wrote: > >> mem_cgroup_read_stat() returns a page count by summing per cpu page >> counters. The summing is racy wrt. updates, so a transient negative sum >> is possible

[PATCH] memcg: remove pcp_counter_lock

Commit 733a572e66d2 ("memcg: make mem_cgroup_read_{stat|event}() iterate possible cpus instead of online") removed the last use of the per memcg pcp_counter_lock but forgot to remove the variable. Kill the vestigial variable. Signed-off-by: Greg Thelen <gthe...@google.com> --

[PATCH] memcg: make mem_cgroup_read_stat() unsigned

shouldn't show confusing negative usage. - tree_usage() already avoids negatives. Avoid returning negative page counts from mem_cgroup_read_stat() and convert it to unsigned. Signed-off-by: Greg Thelen <gthe...@google.com> --- mm/memcontrol.c | 30 ++ 1 file chang

Re: 4.3-rc1 dirty page count underflow (cgroup-related?)

Dave Hansen wrote: > On 09/17/2015 11:09 PM, Greg Thelen wrote: >> I'm not denying the issue, bug the WARNING splat isn't necessarily >> catching a problem. The corresponding code comes from your debug patch: >> + >> WARN_ONCE(__this_cpu_read(memcg->sta

Re: 4.3-rc1 dirty page count underflow (cgroup-related?)

Dave Hansen wrote: > On 09/17/2015 11:09 PM, Greg Thelen wrote: >> I'm not denying the issue, bug the WARNING splat isn't necessarily >> catching a problem. The corresponding code comes from your debug patch: >> + >> WARN_ONCE(__this_cpu_read(memcg->sta

Re: 4.3-rc1 dirty page count underflow (cgroup-related?)

Greg Thelen wrote: > Dave Hansen wrote: > >> I've been seeing some strange behavior with 4.3-rc1 kernels on my Ubuntu >> 14.04.3 system. The system will run fine for a few hours, but suddenly >> start becoming horribly I/O bound. A compile of perf for instanc

Re: 4.3-rc1 dirty page count underflow (cgroup-related?)

Dave Hansen wrote: > I've been seeing some strange behavior with 4.3-rc1 kernels on my Ubuntu > 14.04.3 system. The system will run fine for a few hours, but suddenly > start becoming horribly I/O bound. A compile of perf for instance takes > 20-30 minutes and the compile seems entirely I/O

Re: 4.3-rc1 dirty page count underflow (cgroup-related?)

Dave Hansen wrote: > I've been seeing some strange behavior with 4.3-rc1 kernels on my Ubuntu > 14.04.3 system. The system will run fine for a few hours, but suddenly > start becoming horribly I/O bound. A compile of perf for instance takes > 20-30 minutes and the compile seems entirely I/O

Re: 4.3-rc1 dirty page count underflow (cgroup-related?)

Greg Thelen wrote: > Dave Hansen wrote: > >> I've been seeing some strange behavior with 4.3-rc1 kernels on my Ubuntu >> 14.04.3 system. The system will run fine for a few hours, but suddenly >> start becoming horribly I/O bound. A compile of perf for instanc

Re: [RFC 4/8] jbd, jbd2: Do not fail journal because of frozen_buffer allocation failure

mho...@kernel.org wrote: > From: Michal Hocko > > Journal transaction might fail prematurely because the frozen_buffer > is allocated by GFP_NOFS request: > [ 72.440013] do_get_write_access: OOM for frozen_buffer > [ 72.440014] EXT4-fs: ext4_reserve_inode_write:4729: aborting transaction:

Re: [RFC 4/8] jbd, jbd2: Do not fail journal because of frozen_buffer allocation failure

mho...@kernel.org wrote: From: Michal Hocko mho...@suse.com Journal transaction might fail prematurely because the frozen_buffer is allocated by GFP_NOFS request: [ 72.440013] do_get_write_access: OOM for frozen_buffer [ 72.440014] EXT4-fs: ext4_reserve_inode_write:4729: aborting

Re: [patch v3] mm, hugetlb: abort __get_user_pages if current has been oom killed

> allocating user memory if TIF_MEMDIE is set"), hugetlb page faults now > terminate when the process has been oom killed. > > Cc: Greg Thelen > Cc: Naoya Horiguchi > Cc: Davidlohr Bueso > Acked-by: "Kirill A. Shutemov" > Signed-off-by: David Rientjes L

Re: [patch v2] mm, hugetlb: abort __get_user_pages if current has been oom killed

On Mon, Mar 09 2015, David Rientjes wrote: > If __get_user_pages() is faulting a significant number of hugetlb pages, > usually as the result of mmap(MAP_LOCKED), it can potentially allocate a > very large amount of memory. > > If the process has been oom killed, this will cause a lot of memory

Re: [patch v2] mm, hugetlb: abort __get_user_pages if current has been oom killed

On Mon, Mar 09 2015, David Rientjes wrote: If __get_user_pages() is faulting a significant number of hugetlb pages, usually as the result of mmap(MAP_LOCKED), it can potentially allocate a very large amount of memory. If the process has been oom killed, this will cause a lot of memory to

Re: [patch v3] mm, hugetlb: abort __get_user_pages if current has been oom killed

page faults now terminate when the process has been oom killed. Cc: Greg Thelen gthe...@google.com Cc: Naoya Horiguchi n-horigu...@ah.jp.nec.com Cc: Davidlohr Bueso d...@stgolabs.net Acked-by: Kirill A. Shutemov kir...@shutemov.name Signed-off-by: David Rientjes rient...@google.com Looks good

Re: [RFC] Making memcg track ownership per address_space or anon_vma

On Wed, Feb 11, 2015 at 12:33 PM, Tejun Heo wrote: [...] >> page count to throttle based on blkcg's bandwidth. Note: memcg >> doesn't yet have dirty page counts, but several of us have made >> attempts at adding the counters. And it shouldn't be hard to get them >> merged. > > Can you please

Re: [RFC] Making memcg track ownership per address_space or anon_vma

On Tue, Feb 10, 2015 at 6:19 PM, Tejun Heo wrote: > Hello, again. > > On Sat, Feb 07, 2015 at 09:38:39AM -0500, Tejun Heo wrote: >> If we can argue that memcg and blkcg having different views is >> meaningful and characterize and justify the behaviors stemming from >> the deviation, sure, that'd

Re: [RFC] Making memcg track ownership per address_space or anon_vma

On Tue, Feb 10, 2015 at 6:19 PM, Tejun Heo t...@kernel.org wrote: Hello, again. On Sat, Feb 07, 2015 at 09:38:39AM -0500, Tejun Heo wrote: If we can argue that memcg and blkcg having different views is meaningful and characterize and justify the behaviors stemming from the deviation, sure,

Re: [RFC] Making memcg track ownership per address_space or anon_vma

On Wed, Feb 11, 2015 at 12:33 PM, Tejun Heo t...@kernel.org wrote: [...] page count to throttle based on blkcg's bandwidth. Note: memcg doesn't yet have dirty page counts, but several of us have made attempts at adding the counters. And it shouldn't be hard to get them merged. Can you

Re: [RFC] Making memcg track ownership per address_space or anon_vma

On Fri, Feb 6, 2015 at 6:17 AM, Tejun Heo wrote: > Hello, Greg. > > On Thu, Feb 05, 2015 at 04:03:34PM -0800, Greg Thelen wrote: >> So this is a system which charges all cgroups using a shared inode >> (recharge on read) for all resident pages of that shared inode. The

Re: [RFC] Making memcg track ownership per address_space or anon_vma

On Fri, Feb 6, 2015 at 6:17 AM, Tejun Heo t...@kernel.org wrote: Hello, Greg. On Thu, Feb 05, 2015 at 04:03:34PM -0800, Greg Thelen wrote: So this is a system which charges all cgroups using a shared inode (recharge on read) for all resident pages of that shared inode. There's only

Re: [RFC] Making memcg track ownership per address_space or anon_vma

On Thu, Feb 05 2015, Tejun Heo wrote: > Hey, > > On Thu, Feb 05, 2015 at 02:05:19PM -0800, Greg Thelen wrote: >> >A >> >+-B(usage=2M lim=3M min=2M hosted_usage=2M) >> > +-C (usage=0 lim=2M min=1M shared_usage=2M) >> >

Re: [RFC] Making memcg track ownership per address_space or anon_vma

On Thu, Feb 05 2015, Tejun Heo wrote: > Hello, Greg. > > On Wed, Feb 04, 2015 at 03:51:01PM -0800, Greg Thelen wrote: >> I think the linux-next low (and the TBD min) limits also have the >> problem for more than just the root memcg. I'm thinking of a 2M file >> s

Re: [RFC] Making memcg track ownership per address_space or anon_vma

On Thu, Feb 05 2015, Tejun Heo wrote: Hello, Greg. On Wed, Feb 04, 2015 at 03:51:01PM -0800, Greg Thelen wrote: I think the linux-next low (and the TBD min) limits also have the problem for more than just the root memcg. I'm thinking of a 2M file shared between C and D below. The file

Re: [RFC] Making memcg track ownership per address_space or anon_vma

On Thu, Feb 05 2015, Tejun Heo wrote: Hey, On Thu, Feb 05, 2015 at 02:05:19PM -0800, Greg Thelen wrote: A +-B(usage=2M lim=3M min=2M hosted_usage=2M) +-C (usage=0 lim=2M min=1M shared_usage=2M) +-D (usage=0 lim=2M min=1M shared_usage=2M) \-E (usage=0

Re: [RFC] Making memcg track ownership per address_space or anon_vma

On Wed, Feb 04 2015, Tejun Heo wrote: > Hello, > > On Tue, Feb 03, 2015 at 03:30:31PM -0800, Greg Thelen wrote: >> If a machine has several top level memcg trying to get some form of >> isolation (using low, min, soft limit) then a shared libc will be >> moved t

Re: [RFC] Making memcg track ownership per address_space or anon_vma

On Wed, Feb 04 2015, Tejun Heo wrote: Hello, On Tue, Feb 03, 2015 at 03:30:31PM -0800, Greg Thelen wrote: If a machine has several top level memcg trying to get some form of isolation (using low, min, soft limit) then a shared libc will be moved to the root memcg where it's not protected

Re: [RFC] Making memcg track ownership per address_space or anon_vma

On Mon, Feb 2, 2015 at 11:46 AM, Tejun Heo wrote: > Hey, > > On Mon, Feb 02, 2015 at 10:26:44PM +0300, Konstantin Khlebnikov wrote: > >> Keeping shared inodes in common ancestor is reasonable. >> We could schedule asynchronous moving when somebody opens or mmaps >> inode from outside of its

Re: [RFC] Making memcg track ownership per address_space or anon_vma

On Mon, Feb 2, 2015 at 11:46 AM, Tejun Heo t...@kernel.org wrote: Hey, On Mon, Feb 02, 2015 at 10:26:44PM +0300, Konstantin Khlebnikov wrote: Keeping shared inodes in common ancestor is reasonable. We could schedule asynchronous moving when somebody opens or mmaps inode from outside of its

<    1   2   3   4   >