Re: [PATCH v3] zram: extend zero pages to same element pages

On Mon, Jan 23, 2017 at 10:55:23AM +0900, Minchan Kim wrote: > From: zhouxianrong > > the idea is that without doing more calculations we extend zero pages > to same element pages for zram. zero page is special case of > same element page with zero element. > > 1. the

Re: [PATCH v3] zram: extend zero pages to same element pages

On Mon, Jan 23, 2017 at 10:55:23AM +0900, Minchan Kim wrote: > From: zhouxianrong > > the idea is that without doing more calculations we extend zero pages > to same element pages for zram. zero page is special case of > same element page with zero element. > > 1. the test is done under android

Re: [PATCH] mm: extend zero pages to same element pages for zram

Hello, On Sun, Jan 22, 2017 at 10:58:38AM +0800, zhouxianrong wrote: > 1. memset is just set a int value but i want to set a long value. Sorry for late review. Do we really need to set a long value? I cannot believe that long value is repeated in the page. Value repeatition is usually done by

Re: [PATCH] mm: extend zero pages to same element pages for zram

Hello, On Sun, Jan 22, 2017 at 10:58:38AM +0800, zhouxianrong wrote: > 1. memset is just set a int value but i want to set a long value. Sorry for late review. Do we really need to set a long value? I cannot believe that long value is repeated in the page. Value repeatition is usually done by

Re: [PATCHSET v2] slab: make memcg slab destruction scalable

On Tue, Jan 17, 2017 at 08:49:13AM -0800, Tejun Heo wrote: > Hello, > > On Tue, Jan 17, 2017 at 09:12:57AM +0900, Joonsoo Kim wrote: > > Could you confirm that your series solves the problem that is reported > > by Doug? It would be great if the result is mentioned to the

Re: [PATCHSET v2] slab: make memcg slab destruction scalable

On Tue, Jan 17, 2017 at 08:49:13AM -0800, Tejun Heo wrote: > Hello, > > On Tue, Jan 17, 2017 at 09:12:57AM +0900, Joonsoo Kim wrote: > > Could you confirm that your series solves the problem that is reported > > by Doug? It would be great if the result is mentioned to the

Re: [PATCH] slab: add a check for the first kmem_cache not to be destroyed

On Mon, Jan 16, 2017 at 04:04:59PM +0900, Kyunghwan Kwon wrote: > The first kmem_cache created at booting up is supposed neither mergeable > nor destroyable but was possible to destroy. So prevent it. > > Signed-off-by: Kyunghwan Kwon > --- > mm/slab_common.c | 2 +- > 1 file

Re: [PATCH] slab: add a check for the first kmem_cache not to be destroyed

On Mon, Jan 16, 2017 at 04:04:59PM +0900, Kyunghwan Kwon wrote: > The first kmem_cache created at booting up is supposed neither mergeable > nor destroyable but was possible to destroy. So prevent it. > > Signed-off-by: Kyunghwan Kwon > --- > mm/slab_common.c | 2 +- > 1 file changed, 1

Re: [PATCH 7/8] slab: remove synchronous synchronize_sched() from memcg cache deactivation path

..@kernel.org> > Reported-by: Jay Vana <jsv...@fb.com> > Acked-by: Vladimir Davydov <vdavydov@gmail.com> > Cc: Christoph Lameter <c...@linux.com> > Cc: Pekka Enberg <penb...@kernel.org> > Cc: David Rientjes <rient...@google.com> > Cc: Joonso

Re: [PATCH 7/8] slab: remove synchronous synchronize_sched() from memcg cache deactivation path

eported-by: Jay Vana > Acked-by: Vladimir Davydov > Cc: Christoph Lameter > Cc: Pekka Enberg > Cc: David Rientjes > Cc: Joonsoo Kim > Cc: Andrew Morton > --- > include/linux/slab.h | 6 ++ > mm/slab.h| 2 ++ > mm/slab_common.c | 60 &

Re: [PATCHSET v2] slab: make memcg slab destruction scalable

On Sat, Jan 14, 2017 at 01:48:26PM -0500, Tejun Heo wrote: > This is v2. Changes from the last version[L] are > > * 0002-slab-remove-synchronous-rcu_barrier-call-in-memcg-ca.patch was > incorrect and dropped. > > * 0006-slab-don-t-put-memcg-caches-on-slab_caches-list.patch > incorrectly

Re: [PATCHSET v2] slab: make memcg slab destruction scalable

On Sat, Jan 14, 2017 at 01:48:26PM -0500, Tejun Heo wrote: > This is v2. Changes from the last version[L] are > > * 0002-slab-remove-synchronous-rcu_barrier-call-in-memcg-ca.patch was > incorrect and dropped. > > * 0006-slab-don-t-put-memcg-caches-on-slab_caches-list.patch > incorrectly

Re: [PATCH 2/9] slab: remove synchronous rcu_barrier() call in memcg cache release path

On Sat, Jan 14, 2017 at 10:19:21AM -0500, Tejun Heo wrote: > Hello, Vladimir. > > On Sat, Jan 14, 2017 at 04:19:39PM +0300, Vladimir Davydov wrote: > > On Sat, Jan 14, 2017 at 12:54:42AM -0500, Tejun Heo wrote: > > > This patch updates the cache release path so that it simply uses > > >

Re: [PATCH 2/9] slab: remove synchronous rcu_barrier() call in memcg cache release path

On Sat, Jan 14, 2017 at 10:19:21AM -0500, Tejun Heo wrote: > Hello, Vladimir. > > On Sat, Jan 14, 2017 at 04:19:39PM +0300, Vladimir Davydov wrote: > > On Sat, Jan 14, 2017 at 12:54:42AM -0500, Tejun Heo wrote: > > > This patch updates the cache release path so that it simply uses > > >

Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5

On Mon, Dec 05, 2016 at 09:57:39AM +, Mel Gorman wrote: > On Mon, Dec 05, 2016 at 12:06:19PM +0900, Joonsoo Kim wrote: > > On Fri, Dec 02, 2016 at 09:04:49AM +, Mel Gorman wrote: > > > On Fri, Dec 02, 2016 at 03:03:46PM +0900, Joonsoo Kim wrote: > > > > &g

Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5

On Mon, Dec 05, 2016 at 09:57:39AM +, Mel Gorman wrote: > On Mon, Dec 05, 2016 at 12:06:19PM +0900, Joonsoo Kim wrote: > > On Fri, Dec 02, 2016 at 09:04:49AM +, Mel Gorman wrote: > > > On Fri, Dec 02, 2016 at 03:03:46PM +0900, Joonsoo Kim wrote: > > > > &g

Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5

On Fri, Dec 02, 2016 at 09:21:08AM +0100, Michal Hocko wrote: > On Fri 02-12-16 15:03:46, Joonsoo Kim wrote: > [...] > > > o pcp accounting during free is now confined to free_pcppages_bulk as it's > > > impossible for the caller to know exactly how many pages were freed.

Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5

On Fri, Dec 02, 2016 at 09:21:08AM +0100, Michal Hocko wrote: > On Fri 02-12-16 15:03:46, Joonsoo Kim wrote: > [...] > > > o pcp accounting during free is now confined to free_pcppages_bulk as it's > > > impossible for the caller to know exactly how many pages were freed.

Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5

On Fri, Dec 02, 2016 at 09:04:49AM +, Mel Gorman wrote: > On Fri, Dec 02, 2016 at 03:03:46PM +0900, Joonsoo Kim wrote: > > > @@ -1132,14 +1134,17 @@ static void free_pcppages_bulk(struct zone *zone, > > > int count, > > > if

Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5

On Fri, Dec 02, 2016 at 09:04:49AM +, Mel Gorman wrote: > On Fri, Dec 02, 2016 at 03:03:46PM +0900, Joonsoo Kim wrote: > > > @@ -1132,14 +1134,17 @@ static void free_pcppages_bulk(struct zone *zone, > > > int count, > > > if

Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5

Hello, Mel. I didn't follow up previous discussion so what I raise here would be duplicated. Please let me know the link if it is answered before. On Fri, Dec 02, 2016 at 12:22:44AM +, Mel Gorman wrote: > Changelog since v4 > o Avoid pcp->count getting out of sync if struct page gets

Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5

Hello, Mel. I didn't follow up previous discussion so what I raise here would be duplicated. Please let me know the link if it is answered before. On Fri, Dec 02, 2016 at 12:22:44AM +, Mel Gorman wrote: > Changelog since v4 > o Avoid pcp->count getting out of sync if struct page gets

Re: [PATCH v6 0/6] Introduce ZONE_CMA

On Mon, Nov 07, 2016 at 03:25:01PM +0900, Joonsoo Kim wrote: > On Fri, Oct 14, 2016 at 12:03:10PM +0900, js1...@gmail.com wrote: > > From: Joonsoo Kim <iamjoonsoo@lge.com> > > > > Hello, > > > > Changes from v5 > > o Add acked/reviewed-by tag f

Re: [PATCH v6 0/6] Introduce ZONE_CMA

On Mon, Nov 07, 2016 at 03:25:01PM +0900, Joonsoo Kim wrote: > On Fri, Oct 14, 2016 at 12:03:10PM +0900, js1...@gmail.com wrote: > > From: Joonsoo Kim > > > > Hello, > > > > Changes from v5 > > o Add acked/reviewed-by tag from Vlastimil and Aneesh >

Re: [patch] mm, slab: faster active and free stats

On Fri, Nov 11, 2016 at 02:30:39AM -0800, David Rientjes wrote: > On Fri, 11 Nov 2016, Joonsoo Kim wrote: > > > Hello, David. > > > > Maintaining acitve/free_slab counters looks so complex. And, I think > > that we don't need to maintain these counters for

Re: [patch] mm, slab: faster active and free stats

On Fri, Nov 11, 2016 at 02:30:39AM -0800, David Rientjes wrote: > On Fri, 11 Nov 2016, Joonsoo Kim wrote: > > > Hello, David. > > > > Maintaining acitve/free_slab counters looks so complex. And, I think > > that we don't need to maintain these counters for

Re: [PATCH v6 2/6] mm/cma: introduce new zone, ZONE_CMA

On Tue, Nov 08, 2016 at 02:59:19PM +0800, Chen Feng wrote: > > > On 2016/11/8 11:59, Joonsoo Kim wrote: > > On Mon, Nov 07, 2016 at 03:46:02PM +0800, Chen Feng wrote: > >> > >> > >> On 2016/11/7 15:44, Chen Feng wrote: > >>> On 2016/11/7

Re: [PATCH v6 2/6] mm/cma: introduce new zone, ZONE_CMA

On Tue, Nov 08, 2016 at 02:59:19PM +0800, Chen Feng wrote: > > > On 2016/11/8 11:59, Joonsoo Kim wrote: > > On Mon, Nov 07, 2016 at 03:46:02PM +0800, Chen Feng wrote: > >> > >> > >> On 2016/11/7 15:44, Chen Feng wrote: > >>> On 2016/11/7

Re: [patch] mm, slab: faster active and free stats

On Wed, Nov 09, 2016 at 04:38:08PM -0800, David Rientjes wrote: > On Tue, 8 Nov 2016, Andrew Morton wrote: > > > > Reading /proc/slabinfo or monitoring slabtop(1) can become very expensive > > > if there are many slab caches and if there are very lengthy per-node > > > partial and/or free lists.

Re: [patch] mm, slab: faster active and free stats

On Wed, Nov 09, 2016 at 04:38:08PM -0800, David Rientjes wrote: > On Tue, 8 Nov 2016, Andrew Morton wrote: > > > > Reading /proc/slabinfo or monitoring slabtop(1) can become very expensive > > > if there are many slab caches and if there are very lengthy per-node > > > partial and/or free lists.

Re: [PATCH v6 2/6] mm/cma: introduce new zone, ZONE_CMA

On Mon, Nov 07, 2016 at 03:46:02PM +0800, Chen Feng wrote: > > > On 2016/11/7 15:44, Chen Feng wrote: > > On 2016/11/7 15:27, Joonsoo Kim wrote: > >> On Mon, Nov 07, 2016 at 03:08:49PM +0800, Chen Feng wrote: > >>> > >>> > >>> On 201

Re: [PATCH v6 2/6] mm/cma: introduce new zone, ZONE_CMA

On Mon, Nov 07, 2016 at 03:46:02PM +0800, Chen Feng wrote: > > > On 2016/11/7 15:44, Chen Feng wrote: > > On 2016/11/7 15:27, Joonsoo Kim wrote: > >> On Mon, Nov 07, 2016 at 03:08:49PM +0800, Chen Feng wrote: > >>> > >>> > >>> On 201

Re: [PATCH v6 2/6] mm/cma: introduce new zone, ZONE_CMA

On Mon, Nov 07, 2016 at 03:08:49PM +0800, Chen Feng wrote: > > > On 2016/11/7 14:15, Joonsoo Kim wrote: > > On Tue, Nov 01, 2016 at 03:58:32PM +0800, Chen Feng wrote: > >> Hello, I hava a question on cma zone. > >> > >> When we have cma zone, c

Re: [PATCH v6 2/6] mm/cma: introduce new zone, ZONE_CMA

On Mon, Nov 07, 2016 at 03:08:49PM +0800, Chen Feng wrote: > > > On 2016/11/7 14:15, Joonsoo Kim wrote: > > On Tue, Nov 01, 2016 at 03:58:32PM +0800, Chen Feng wrote: > >> Hello, I hava a question on cma zone. > >> > >> When we have cma zone, c

Re: [PATCH v6 0/6] Introduce ZONE_CMA

On Fri, Oct 14, 2016 at 12:03:10PM +0900, js1...@gmail.com wrote: > From: Joonsoo Kim <iamjoonsoo@lge.com> > > Hello, > > Changes from v5 > o Add acked/reviewed-by tag from Vlastimil and Aneesh > o Rebase on next-20161013 > o Cosmetic change on patch 1

Re: [PATCH v6 0/6] Introduce ZONE_CMA

On Fri, Oct 14, 2016 at 12:03:10PM +0900, js1...@gmail.com wrote: > From: Joonsoo Kim > > Hello, > > Changes from v5 > o Add acked/reviewed-by tag from Vlastimil and Aneesh > o Rebase on next-20161013 > o Cosmetic change on patch 1 > o Optimize span of ZONE_CMA on

Re: [PATCH v6 2/6] mm/cma: introduce new zone, ZONE_CMA

On Tue, Nov 01, 2016 at 03:58:32PM +0800, Chen Feng wrote: > Hello, I hava a question on cma zone. > > When we have cma zone, cma zone will be the highest zone of system. > > In android system, the most memory allocator is ION. Media system will > alloc unmovable memory from it. > > On low

Re: [PATCH v6 2/6] mm/cma: introduce new zone, ZONE_CMA

On Tue, Nov 01, 2016 at 03:58:32PM +0800, Chen Feng wrote: > Hello, I hava a question on cma zone. > > When we have cma zone, cma zone will be the highest zone of system. > > In android system, the most memory allocator is ION. Media system will > alloc unmovable memory from it. > > On low

Re: [v3,6/9] mm/page_owner: use stackdepot to store stacktrace

Hello, Thanks for the report. On Wed, Oct 26, 2016 at 03:06:05PM +0200, Sascha Silbe wrote: > Dear Joonsoo, > > Joonsoo Kim <js1...@gmail.com> writes: > > > Currently, we store each page's allocation stacktrace on corresponding > > page_ext structure a

Re: [v3,6/9] mm/page_owner: use stackdepot to store stacktrace

Hello, Thanks for the report. On Wed, Oct 26, 2016 at 03:06:05PM +0200, Sascha Silbe wrote: > Dear Joonsoo, > > Joonsoo Kim writes: > > > Currently, we store each page's allocation stacktrace on corresponding > > page_ext structure and it requires a lot of memory. Thi

Re: [RFC PATCH 1/5] mm/page_alloc: always add freeing page at the tail of the buddy list

On Wed, Oct 26, 2016 at 01:50:37PM +0800, Xishi Qiu wrote: > On 2016/10/26 12:37, Joonsoo Kim wrote: > > > On Mon, Oct 17, 2016 at 05:21:54PM +0800, Xishi Qiu wrote: > >> On 2016/10/13 16:08, js1...@gmail.com wrote: > >> > >>> From: Joonsoo Kim <

Re: [RFC PATCH 1/5] mm/page_alloc: always add freeing page at the tail of the buddy list

On Wed, Oct 26, 2016 at 01:50:37PM +0800, Xishi Qiu wrote: > On 2016/10/26 12:37, Joonsoo Kim wrote: > > > On Mon, Oct 17, 2016 at 05:21:54PM +0800, Xishi Qiu wrote: > >> On 2016/10/13 16:08, js1...@gmail.com wrote: > >> > >>> From: Joonsoo Kim > >

Re: [RFC PATCH 2/5] mm/page_alloc: use smallest fallback page first in movable allocation

On Fri, Oct 14, 2016 at 12:52:26PM +0200, Vlastimil Babka wrote: > On 10/14/2016 03:26 AM, Joonsoo Kim wrote: > >On Thu, Oct 13, 2016 at 11:12:10AM +0200, Vlastimil Babka wrote: > >>On 10/13/2016 10:08 AM, js1...@gmail.com wrote: > >>>From: Joonsoo Kim <iamjoonso

Re: [RFC PATCH 2/5] mm/page_alloc: use smallest fallback page first in movable allocation

On Fri, Oct 14, 2016 at 12:52:26PM +0200, Vlastimil Babka wrote: > On 10/14/2016 03:26 AM, Joonsoo Kim wrote: > >On Thu, Oct 13, 2016 at 11:12:10AM +0200, Vlastimil Babka wrote: > >>On 10/13/2016 10:08 AM, js1...@gmail.com wrote: > >>>From: Joonsoo Kim > >

Re: [RFC PATCH 1/5] mm/page_alloc: always add freeing page at the tail of the buddy list

On Mon, Oct 17, 2016 at 05:21:54PM +0800, Xishi Qiu wrote: > On 2016/10/13 16:08, js1...@gmail.com wrote: > > > From: Joonsoo Kim <iamjoonsoo@lge.com> > > > > Currently, freeing page can stay longer in the buddy list if next higher > > order page i

Re: [RFC PATCH 1/5] mm/page_alloc: always add freeing page at the tail of the buddy list

On Mon, Oct 17, 2016 at 05:21:54PM +0800, Xishi Qiu wrote: > On 2016/10/13 16:08, js1...@gmail.com wrote: > > > From: Joonsoo Kim > > > > Currently, freeing page can stay longer in the buddy list if next higher > > order page is in the buddy list in orde

Re: [PATCH v6 3/6] mm/cma: populate ZONE_CMA

On Tue, Oct 18, 2016 at 05:27:30PM +0900, Joonsoo Kim wrote: > On Tue, Oct 18, 2016 at 09:42:57AM +0200, Vlastimil Babka wrote: > > On 10/14/2016 05:03 AM, js1...@gmail.com wrote: > > >@@ -145,6 +145,35 @@ static int __init cma_activate_area(struct cma *cma) >

Re: [PATCH v6 3/6] mm/cma: populate ZONE_CMA

On Tue, Oct 18, 2016 at 05:27:30PM +0900, Joonsoo Kim wrote: > On Tue, Oct 18, 2016 at 09:42:57AM +0200, Vlastimil Babka wrote: > > On 10/14/2016 05:03 AM, js1...@gmail.com wrote: > > >@@ -145,6 +145,35 @@ static int __init cma_activate_area(struct cma *cma) >

Re: [PATCH v6 3/6] mm/cma: populate ZONE_CMA

On Tue, Oct 18, 2016 at 09:42:57AM +0200, Vlastimil Babka wrote: > On 10/14/2016 05:03 AM, js1...@gmail.com wrote: > >@@ -145,6 +145,35 @@ static int __init cma_activate_area(struct cma *cma) > > static int __init cma_init_reserved_areas(void) > > { > > int i; > >+struct zone *zone; > >+

Re: [PATCH v6 3/6] mm/cma: populate ZONE_CMA

On Tue, Oct 18, 2016 at 09:42:57AM +0200, Vlastimil Babka wrote: > On 10/14/2016 05:03 AM, js1...@gmail.com wrote: > >@@ -145,6 +145,35 @@ static int __init cma_activate_area(struct cma *cma) > > static int __init cma_init_reserved_areas(void) > > { > > int i; > >+struct zone *zone; > >+

Re: [RFC PATCH 5/5] mm/page_alloc: support fixed migratetype pageblock

On Thu, Oct 13, 2016 at 01:05:11PM +0200, Vlastimil Babka wrote: > On 10/13/2016 10:08 AM, js1...@gmail.com wrote: > >From: Joonsoo Kim <iamjoonsoo@lge.com> > > > >We have migratetype facility to minimise fragmentation. It dynamically > >changes migratetype of

Re: [RFC PATCH 5/5] mm/page_alloc: support fixed migratetype pageblock

On Thu, Oct 13, 2016 at 01:05:11PM +0200, Vlastimil Babka wrote: > On 10/13/2016 10:08 AM, js1...@gmail.com wrote: > >From: Joonsoo Kim > > > >We have migratetype facility to minimise fragmentation. It dynamically > >changes migratetype of pageblock based on

Re: [RFC PATCH 3/5] mm/page_alloc: stop instantly reusing freed page

On Thu, Oct 13, 2016 at 12:59:14PM +0200, Vlastimil Babka wrote: > On 10/13/2016 10:08 AM, js1...@gmail.com wrote: > >From: Joonsoo Kim <iamjoonsoo@lge.com> > > > >Allocation/free pattern is usually sequantial. If they are freed to > >the buddy list, they ca

Re: [RFC PATCH 3/5] mm/page_alloc: stop instantly reusing freed page

On Thu, Oct 13, 2016 at 12:59:14PM +0200, Vlastimil Babka wrote: > On 10/13/2016 10:08 AM, js1...@gmail.com wrote: > >From: Joonsoo Kim > > > >Allocation/free pattern is usually sequantial. If they are freed to > >the buddy list, they can be coalesced. However, we firs

Re: [RFC PATCH 2/5] mm/page_alloc: use smallest fallback page first in movable allocation

On Thu, Oct 13, 2016 at 11:12:10AM +0200, Vlastimil Babka wrote: > On 10/13/2016 10:08 AM, js1...@gmail.com wrote: > >From: Joonsoo Kim <iamjoonsoo@lge.com> > > > >When we try to find freepage in fallback buddy list, we always serach > >the largest one. This w

Re: [RFC PATCH 2/5] mm/page_alloc: use smallest fallback page first in movable allocation

On Thu, Oct 13, 2016 at 11:12:10AM +0200, Vlastimil Babka wrote: > On 10/13/2016 10:08 AM, js1...@gmail.com wrote: > >From: Joonsoo Kim > > > >When we try to find freepage in fallback buddy list, we always serach > >the largest one. This would help for fragmentation

Re: [RFC PATCH 1/5] mm/page_alloc: always add freeing page at the tail of the buddy list

On Thu, Oct 13, 2016 at 11:04:39AM +0200, Vlastimil Babka wrote: > On 10/13/2016 10:08 AM, js1...@gmail.com wrote: > >From: Joonsoo Kim <iamjoonsoo@lge.com> > > > >Currently, freeing page can stay longer in the buddy list if next higher > >order page is i

Re: [RFC PATCH 1/5] mm/page_alloc: always add freeing page at the tail of the buddy list

On Thu, Oct 13, 2016 at 11:04:39AM +0200, Vlastimil Babka wrote: > On 10/13/2016 10:08 AM, js1...@gmail.com wrote: > >From: Joonsoo Kim > > > >Currently, freeing page can stay longer in the buddy list if next higher > >order page is in the buddy list in order t

Re: [RFC 4/4] mm, page_alloc: disallow migratetype fallback in fastpath

On Thu, Sep 29, 2016 at 11:05:48PM +0200, Vlastimil Babka wrote: > The previous patch has adjusted async compaction so that it helps against > longterm fragmentation when compacting for a non-MOVABLE high-order > allocation. > The goal of this patch is to force such allocations go through

Re: [RFC 4/4] mm, page_alloc: disallow migratetype fallback in fastpath

On Thu, Sep 29, 2016 at 11:05:48PM +0200, Vlastimil Babka wrote: > The previous patch has adjusted async compaction so that it helps against > longterm fragmentation when compacting for a non-MOVABLE high-order > allocation. > The goal of this patch is to force such allocations go through

Re: [PATCH] mm/slab: fix kmemcg cache creation delayed issue

On Fri, Oct 07, 2016 at 10:20:55AM +0200, Michal Hocko wrote: > On Fri 07-10-16 14:14:01, Joonsoo Kim wrote: > > On Thu, Oct 06, 2016 at 09:02:00AM -0700, Doug Smythies wrote: > > > It was my (limited) understanding that the subsequent 2 patch set > > > superseded this

Re: [PATCH] mm/slab: fix kmemcg cache creation delayed issue

On Fri, Oct 07, 2016 at 10:20:55AM +0200, Michal Hocko wrote: > On Fri 07-10-16 14:14:01, Joonsoo Kim wrote: > > On Thu, Oct 06, 2016 at 09:02:00AM -0700, Doug Smythies wrote: > > > It was my (limited) understanding that the subsequent 2 patch set > > > superseded this

Re: Regression in mobility grouping?

Sorry for late response. On Thu, Sep 29, 2016 at 12:14:02PM -0400, Johannes Weiner wrote: > On Thu, Sep 29, 2016 at 03:14:33PM +0900, Joonsoo Kim wrote: > > On Wed, Sep 28, 2016 at 10:25:40PM -0400, Johannes Weiner wrote: > > > On Wed, Sep 28, 2016 at 11:39:25AM -0400, Joh

Re: Regression in mobility grouping?

Sorry for late response. On Thu, Sep 29, 2016 at 12:14:02PM -0400, Johannes Weiner wrote: > On Thu, Sep 29, 2016 at 03:14:33PM +0900, Joonsoo Kim wrote: > > On Wed, Sep 28, 2016 at 10:25:40PM -0400, Johannes Weiner wrote: > > > On Wed, Sep 28, 2016 at 11:39:25AM -0400, Joh

Re: [PATCH] mm/slab: fix kmemcg cache creation delayed issue

On Thu, Oct 06, 2016 at 09:02:00AM -0700, Doug Smythies wrote: > It was my (limited) understanding that the subsequent 2 patch set > superseded this patch. Indeed, the 2 patch set seems to solve > both the SLAB and SLUB bug reports. It would mean that patch 1 solves both the SLAB and SLUB bug

Re: [PATCH] mm/slab: fix kmemcg cache creation delayed issue

On Thu, Oct 06, 2016 at 09:02:00AM -0700, Doug Smythies wrote: > It was my (limited) understanding that the subsequent 2 patch set > superseded this patch. Indeed, the 2 patch set seems to solve > both the SLAB and SLUB bug reports. It would mean that patch 1 solves both the SLAB and SLUB bug

Re: [PATCH 2/2] slub: move synchronize_sched out of slab_mutex on shrink

; > Cc: Christoph Lameter <c...@linux.com> > Cc: David Rientjes <rient...@google.com> > Cc: Johannes Weiner <han...@cmpxchg.org> > Cc: Joonsoo Kim <iamjoonsoo@lge.com> > Cc: Michal Hocko <mho...@kernel.org> > Cc: Pekka Enberg <penb...@kerne

Re: [PATCH 2/2] slub: move synchronize_sched out of slab_mutex on shrink

we can also move it out > of the slab_mutex, which we have to hold for iterating over the slab > cache list. > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=172991 > Signed-off-by: Vladimir Davydov > Reported-by: Doug Smythies > Cc: Christoph Lameter > Cc: David Rientjes > C

Re: Regression in mobility grouping?

On Wed, Sep 28, 2016 at 10:25:40PM -0400, Johannes Weiner wrote: > On Wed, Sep 28, 2016 at 11:39:25AM -0400, Johannes Weiner wrote: > > On Wed, Sep 28, 2016 at 11:00:15AM +0200, Vlastimil Babka wrote: > > > I guess testing revert of 9c0415e could give us some idea. Commit > > > 3a1086f shouldn't

Re: Regression in mobility grouping?

On Wed, Sep 28, 2016 at 10:25:40PM -0400, Johannes Weiner wrote: > On Wed, Sep 28, 2016 at 11:39:25AM -0400, Johannes Weiner wrote: > > On Wed, Sep 28, 2016 at 11:00:15AM +0200, Vlastimil Babka wrote: > > > I guess testing revert of 9c0415e could give us some idea. Commit > > > 3a1086f shouldn't

Re: [RFC] mm: a question about high-order check in __zone_watermark_ok()

On Mon, Sep 26, 2016 at 01:02:31PM +0200, Michal Hocko wrote: > On Mon 26-09-16 18:17:50, Xishi Qiu wrote: > > On 2016/9/26 17:43, Michal Hocko wrote: > > > > > On Mon 26-09-16 17:16:54, Xishi Qiu wrote: > > >> On 2016/9/26 16:58, Michal Hocko wrote: > > >> > > >>> On Mon 26-09-16 16:47:57, Xishi

Re: [RFC] mm: a question about high-order check in __zone_watermark_ok()

On Mon, Sep 26, 2016 at 01:02:31PM +0200, Michal Hocko wrote: > On Mon 26-09-16 18:17:50, Xishi Qiu wrote: > > On 2016/9/26 17:43, Michal Hocko wrote: > > > > > On Mon 26-09-16 17:16:54, Xishi Qiu wrote: > > >> On 2016/9/26 16:58, Michal Hocko wrote: > > >> > > >>> On Mon 26-09-16 16:47:57, Xishi

Re: [PATCH v5 3/6] mm/cma: populate ZONE_CMA

On Thu, Sep 22, 2016 at 05:59:46PM +0200, Vlastimil Babka wrote: > On 09/22/2016 08:50 AM, Joonsoo Kim wrote: > >On Thu, Sep 22, 2016 at 02:45:46PM +0900, Joonsoo Kim wrote: > >>> > >>> > /* Free whole pageblock and set its migration type to

Re: [PATCH v5 3/6] mm/cma: populate ZONE_CMA

On Thu, Sep 22, 2016 at 05:59:46PM +0200, Vlastimil Babka wrote: > On 09/22/2016 08:50 AM, Joonsoo Kim wrote: > >On Thu, Sep 22, 2016 at 02:45:46PM +0900, Joonsoo Kim wrote: > >>> > >>> > /* Free whole pageblock and set its migration type to

Re: [PATCH 5/7] slab, workqueue: remove keventd_up() usage

g> > Cc: Christoph Lameter <c...@linux.com> > Cc: Pekka Enberg <penb...@kernel.org> > Cc: David Rientjes <rient...@google.com> > Cc: Joonsoo Kim <iamjoonsoo@lge.com> > Cc: Andrew Morton <a...@linux-foundation.org> > Cc: linux...@kvack.org

Re: [PATCH 5/7] slab, workqueue: remove keventd_up() usage

meter > Cc: Pekka Enberg > Cc: David Rientjes > Cc: Joonsoo Kim > Cc: Andrew Morton > Cc: linux...@kvack.org > --- > Hello, > > This change depends on an earlier workqueue patch and is followed by a > patch to remove keventd_up(). It'd be great if it can b

Re: [PATCH v5 3/6] mm/cma: populate ZONE_CMA

On Thu, Sep 22, 2016 at 02:45:46PM +0900, Joonsoo Kim wrote: > On Wed, Sep 21, 2016 at 11:20:11AM +0200, Vlastimil Babka wrote: > > On 08/29/2016 07:07 AM, js1...@gmail.com wrote: > > >From: Joonsoo Kim <iamjoonsoo@lge.com> > > > > > >Unt

Re: [PATCH v5 3/6] mm/cma: populate ZONE_CMA

On Thu, Sep 22, 2016 at 02:45:46PM +0900, Joonsoo Kim wrote: > On Wed, Sep 21, 2016 at 11:20:11AM +0200, Vlastimil Babka wrote: > > On 08/29/2016 07:07 AM, js1...@gmail.com wrote: > > >From: Joonsoo Kim > > > > > >Until now, reserved pages for CMA are mana

Re: [PATCH v5 3/6] mm/cma: populate ZONE_CMA

On Wed, Sep 21, 2016 at 11:20:11AM +0200, Vlastimil Babka wrote: > On 08/29/2016 07:07 AM, js1...@gmail.com wrote: > >From: Joonsoo Kim <iamjoonsoo@lge.com> > > > >Until now, reserved pages for CMA are managed in the ordinary zones > >where page's pfn are belo

Re: [PATCH v5 3/6] mm/cma: populate ZONE_CMA

On Wed, Sep 21, 2016 at 11:20:11AM +0200, Vlastimil Babka wrote: > On 08/29/2016 07:07 AM, js1...@gmail.com wrote: > >From: Joonsoo Kim > > > >Until now, reserved pages for CMA are managed in the ordinary zones > >where page's pfn are belong to. This approach has numo

Re: [PATCH v5 0/6] Introduce ZONE_CMA

On Wed, Sep 21, 2016 at 08:17:27PM +0530, Aneesh Kumar K.V wrote: > "Aneesh Kumar K.V" <aneesh.ku...@linux.vnet.ibm.com> writes: > > > Joonsoo Kim <iamjoonsoo@lge.com> writes: > > > >> On Tue, Aug 30, 2016 at 04:09:37PM +0530, Aneesh Kum

Re: [PATCH v5 0/6] Introduce ZONE_CMA

On Wed, Sep 21, 2016 at 08:17:27PM +0530, Aneesh Kumar K.V wrote: > "Aneesh Kumar K.V" writes: > > > Joonsoo Kim writes: > > > >> On Tue, Aug 30, 2016 at 04:09:37PM +0530, Aneesh Kumar K.V wrote: > >>> Joonsoo Kim writes: > >

Re: [PATCH v5 1/6] mm/page_alloc: don't reserve ZONE_HIGHMEM for ZONE_MOVABLE request

On Fri, Sep 16, 2016 at 08:44:17AM +0530, Aneesh Kumar K.V wrote: > js1...@gmail.com writes: > > > From: Joonsoo Kim <iamjoonsoo@lge.com> > > > > Freepage on ZONE_HIGHMEM doesn't work for kernel memory so it's not that > > important to reserve. When ZONE

Re: [PATCH v5 1/6] mm/page_alloc: don't reserve ZONE_HIGHMEM for ZONE_MOVABLE request

On Fri, Sep 16, 2016 at 08:44:17AM +0530, Aneesh Kumar K.V wrote: > js1...@gmail.com writes: > > > From: Joonsoo Kim > > > > Freepage on ZONE_HIGHMEM doesn't work for kernel memory so it's not that > > important to reserve. When ZONE_MOVABLE is used, this problem

Re: [PATCH v5 0/6] Introduce ZONE_CMA

On Thu, Sep 01, 2016 at 11:17:23AM +0530, Aneesh Kumar K.V wrote: > Joonsoo Kim <iamjoonsoo@lge.com> writes: > > > On Tue, Aug 30, 2016 at 04:09:37PM +0530, Aneesh Kumar K.V wrote: > >> Joonsoo Kim <js1...@gmail.com> writes: > >> > >

Re: [PATCH v5 0/6] Introduce ZONE_CMA

On Thu, Sep 01, 2016 at 11:17:23AM +0530, Aneesh Kumar K.V wrote: > Joonsoo Kim writes: > > > On Tue, Aug 30, 2016 at 04:09:37PM +0530, Aneesh Kumar K.V wrote: > >> Joonsoo Kim writes: > >> > >> > 2016-08-29 18:27 GMT+09:00 Aneesh Kumar K.V

Re: [PATCH v5 0/6] Introduce ZONE_CMA

On Tue, Aug 30, 2016 at 04:09:37PM +0530, Aneesh Kumar K.V wrote: > Joonsoo Kim <js1...@gmail.com> writes: > > > 2016-08-29 18:27 GMT+09:00 Aneesh Kumar K.V > > <aneesh.ku...@linux.vnet.ibm.com>: > >> js1...@gmail.com writes: > >>

Re: [PATCH v5 0/6] Introduce ZONE_CMA

On Tue, Aug 30, 2016 at 04:09:37PM +0530, Aneesh Kumar K.V wrote: > Joonsoo Kim writes: > > > 2016-08-29 18:27 GMT+09:00 Aneesh Kumar K.V > > : > >> js1...@gmail.com writes: > >> > >>> From: Joonsoo Kim > >>> > >>> Hello,

Re: [PATCH v5 2/6] mm/cma: introduce new zone, ZONE_CMA

On Tue, Aug 30, 2016 at 06:10:46PM +0530, Aneesh Kumar K.V wrote: > "Aneesh Kumar K.V" writes: > > > > > > >> static inline void check_highest_zone(enum zone_type k) > >> { > >> - if (k > policy_zone && k != ZONE_MOVABLE) > >> + if (k > policy_zone && k

Re: [PATCH v5 2/6] mm/cma: introduce new zone, ZONE_CMA

On Tue, Aug 30, 2016 at 06:10:46PM +0530, Aneesh Kumar K.V wrote: > "Aneesh Kumar K.V" writes: > > > > > > >> static inline void check_highest_zone(enum zone_type k) > >> { > >> - if (k > policy_zone && k != ZONE_MOVABLE) > >> + if (k > policy_zone && k != ZONE_MOVABLE &&

Re: [PATCH v5 0/6] Introduce ZONE_CMA

2016-08-29 18:27 GMT+09:00 Aneesh Kumar K.V <aneesh.ku...@linux.vnet.ibm.com>: > js1...@gmail.com writes: > >> From: Joonsoo Kim <iamjoonsoo@lge.com> >> >> Hello, >> >> Changes from v4 >> o Rebase on next-20160825 >> o Add general fix

Re: [PATCH v5 0/6] Introduce ZONE_CMA

2016-08-29 18:27 GMT+09:00 Aneesh Kumar K.V : > js1...@gmail.com writes: > >> From: Joonsoo Kim >> >> Hello, >> >> Changes from v4 >> o Rebase on next-20160825 >> o Add general fix patch for lowmem reserve >> o Fix lowmem reserve ratio >>

Re: OOM detection regressions since 4.7

2016-08-24 16:04 GMT+09:00 Michal Hocko <mho...@kernel.org>: > On Wed 24-08-16 14:01:57, Joonsoo Kim wrote: >> Looks like my mail client eat my reply so I resend. >> >> On Tue, Aug 23, 2016 at 09:33:18AM +0200, Michal Hocko wrote: >> > On Tue

Re: OOM detection regressions since 4.7

2016-08-24 16:04 GMT+09:00 Michal Hocko : > On Wed 24-08-16 14:01:57, Joonsoo Kim wrote: >> Looks like my mail client eat my reply so I resend. >> >> On Tue, Aug 23, 2016 at 09:33:18AM +0200, Michal Hocko wrote: >> > On Tue 23-08-16 13:52:45, Joonsoo Kim wrote: &

Re: OOM detection regressions since 4.7

Looks like my mail client eat my reply so I resend. On Tue, Aug 23, 2016 at 09:33:18AM +0200, Michal Hocko wrote: > On Tue 23-08-16 13:52:45, Joonsoo Kim wrote: > [...] > > Hello, Michal. > > > > I agree with partial revert but revert should be a different form. >

Re: OOM detection regressions since 4.7

Looks like my mail client eat my reply so I resend. On Tue, Aug 23, 2016 at 09:33:18AM +0200, Michal Hocko wrote: > On Tue 23-08-16 13:52:45, Joonsoo Kim wrote: > [...] > > Hello, Michal. > > > > I agree with partial revert but revert should be a different form. >

Re: what is the purpose of SLAB and SLUB (was: Re: [PATCH v3] mm/slab: Improve performance of gathering slabinfo) stats

On Tue, Aug 23, 2016 at 05:38:08PM +0200, Michal Hocko wrote: > On Tue 23-08-16 11:13:03, Joonsoo Kim wrote: > > On Thu, Aug 18, 2016 at 01:52:19PM +0200, Michal Hocko wrote: > [...] > > > I am not opposing the patch (to be honest it is quite neat) but this > > >

Re: what is the purpose of SLAB and SLUB (was: Re: [PATCH v3] mm/slab: Improve performance of gathering slabinfo) stats

On Tue, Aug 23, 2016 at 05:38:08PM +0200, Michal Hocko wrote: > On Tue 23-08-16 11:13:03, Joonsoo Kim wrote: > > On Thu, Aug 18, 2016 at 01:52:19PM +0200, Michal Hocko wrote: > [...] > > > I am not opposing the patch (to be honest it is quite neat) but this > > >

Re: OOM detection regressions since 4.7

On Mon, Aug 22, 2016 at 11:32:49AM +0200, Michal Hocko wrote: > Hi, > there have been multiple reports [1][2][3][4][5] about pre-mature OOM > killer invocations since 4.7 which contains oom detection rework. All of > them were for order-2 (kernel stack) alloaction requests failing because > of a

Re: OOM detection regressions since 4.7

On Mon, Aug 22, 2016 at 11:32:49AM +0200, Michal Hocko wrote: > Hi, > there have been multiple reports [1][2][3][4][5] about pre-mature OOM > killer invocations since 4.7 which contains oom detection rework. All of > them were for order-2 (kernel stack) alloaction requests failing because > of a

<    1   2   3   4   5   6   7   8   9   10   >