[PATCH v5] mm: multi-gen LRU: reuse some legacy trace events

-by: Jaewon Kim Acked-by: Yu Zhao --- v5: reuse the legacy trace events v4: wrap with #ifdef CONFIG_LRU_GEN v3: change printk format v2: use condition and make it aligned v1: introduce trace events --- mm/vmscan.c | 18 +- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git

Re: [PATCH v4] vmscan: add trace events for lru_gen

Hello Yu Zhao Could you give me your comment? I am waiting for your opinion on the reuse method. I'm planning to resend it as a complete patch with it. Thank you. On Tue, Sep 26, 2023 at 11:15 PM 김재원 wrote: > > >>>On Mon, Sep 25, 2023 at 10:20?PM Jaewon K

[PATCH v4] vmscan: add trace events for lru_gen

nr_activate_anon=0 nr_activate_file=0 nr_ref_keep=0 nr_unmap_fail=0 priority=12 flags=RECLAIM_WB_FILE|RECLAIM_WB_ASYNC Signed-off-by: Jaewon Kim --- v4: wrap with #ifdef CONFIG_LRU_GEN v3: change printk format v2: use condition and make it aligned v1: introduce trace events --- include/trace/events/mmflags.h

[PATCH v3] vmscan: add trace events for lru_gen

=0 nr_immediate=0 nr_activate_anon=0 nr_activate_file=2 nr_ref_keep=0 nr_unmap_fail=0 priority=2 flags=RECLAIM_WB_FILE|RECLAIM_WB_ASYNC Signed-off-by: Jaewon Kim Reviewed-by: Steven Rostedt (Google) Reviewed-by: T.J. Mercier --- v3: change printk format v2: use condition and make it aligned v1

[PATCH v2] vmscan: add trace events for lru_gen

=0 nr_immediate=0 nr_activate_anon=0 nr_activate_file=2 nr_ref_keep=0 nr_unmap_fail=0 priority=2 flags=RECLAIM_WB_FILE|RECLAIM_WB_ASYNC Signed-off-by: Jaewon Kim --- v2: use condition and make it aligned v1: introduce trace events --- include/trace/events/mmflags.h | 5 ++ include/trace/events

[PATCH] vmscan: add trace events for lru_gen

=0 nr_immediate=0 nr_activate_anon=0 nr_activate_file=2 nr_ref_keep=0 nr_unmap_fail=0 priority=2 flags=RECLAIM_WB_FILE|RECLAIM_WB_ASYNC Signed-off-by: Jaewon Kim --- include/trace/events/mmflags.h | 5 ++ include/trace/events/vmscan.h | 96 ++ mm/vmscan.c

[PATCH v5] page_alloc: consider highatomic reserve in watermark fast

_GFP_ZERO <...>-22275 [006] 889.213396: mm_page_alloc: page=f6b72a64 pfn=970197 order=0 migratetype=0 nr_free=3650 gfp_flags=GFP_HIGHUSER|__GFP_ZERO kswapd0-1207 [005] ...1 889.213398: mm_page_alloc: page= (null) pfn=0 order=0 migratetype=1 nr_free=3650 gfp_flag

[PATCH v4] page_alloc: consider highatomic reserve in watermark fast

_GFP_ZERO <...>-22275 [006] 889.213396: mm_page_alloc: page=f6b72a64 pfn=970197 order=0 migratetype=0 nr_free=3650 gfp_flags=GFP_HIGHUSER|__GFP_ZERO kswapd0-1207 [005] ...1 889.213398: mm_page_alloc: page= (null) pfn=0 order=0 migratetype=1 nr_free=3650 gfp_flags=GFP_

Re: (2) [PATCH v2] page_alloc: consider highatomic reserve in wmartermark fast

., 2020년 6월 16일 (화) 오후 11:17, Baoquan He 님이 작성: > > On 06/16/20 at 04:30pm, 김재원 wrote: > > >>> > > <4>[ 6207.637627] [3: Binder:9343_3:22875] Normal free:10908kB > > >>> > > min:6192kB low:44388kB high:47060kB active_anon:409160kB > > >>> > > inactive_anon:325924kB active_file:235820kB

Re: [PATCH v3] page_alloc: consider highatomic reserve in wmartermark fast

2020년 6월 16일 (화) 오후 7:21, Vlastimil Babka 님이 작성: > > On 6/17/20 4:05 AM, Jaewon Kim wrote: > > Please fix typo "wmartermark" in subject. Oops Let me fix typo in next version as watermark > > > zone_watermark_fast was introduced by commit 48ee5f3696f6 ("mm, >

[PATCH v3] page_alloc: consider highatomic reserve in wmartermark fast

fp_flags=GFP_HIGHUSER|__GFP_ZERO <...>-22275 [006] 889.213396: mm_page_alloc: page=0000f6b72a64 pfn=970197 order=0 migratetype=0 nr_free=3650 gfp_flags=GFP_HIGHUSER|__GFP_ZERO kswapd0-1207 [005] ...1 889.213398: mm_page_alloc: page= (null) pfn=0 order=0 migratetype=

Re: [PATCH v2] page_alloc: consider highatomic reserve in wmartermark fast

2020년 6월 13일 (토) 오후 6:42, Baoquan He 님이 작성: > > On 06/13/20 at 11:51am, Jaewon Kim wrote: > > zone_watermark_fast was introduced by commit 48ee5f3696f6 ("mm, > > page_alloc: shortcut watermark checks for order-0 pages"). The commit > > simply checks if free page

[PATCH v2] page_alloc: consider highatomic reserve in wmartermark fast

80kB active_file:396196kB inactive_file:677284kB unevictable:193168kB writepending:2304kB present:4081664kB managed:3593324kB mlocked:193168kB kernel_stack:55008kB pagetables:100352kB bounce:0kB free_pcp:1776kB local_pcp:656kB free_cma:12kB <4>[ 156.701741] [4:kswapd0: 1209] low

Re: [PATCH] page_alloc: consider highatomic reserve in wmartermark fast

On 2020년 06월 12일 16:40, Minchan Kim wrote: > On Fri, Jun 12, 2020 at 04:03:41PM +0900, Jaewon Kim wrote: >> >> On 2020년 06월 12일 15:55, Minchan Kim wrote: >>> On Thu, Jun 11, 2020 at 05:54:12PM +0900, Jaewon Kim wrote: >>>> On 2020년 06월 10일 10:21

Re: [PATCH] page_alloc: consider highatomic reserve in wmartermark fast

On 2020년 06월 12일 15:55, Minchan Kim wrote: > On Thu, Jun 11, 2020 at 05:54:12PM +0900, Jaewon Kim wrote: >> >> On 2020년 06월 10일 10:21, Minchan Kim wrote: >>> Hi Jaewon, >>> >>> On Tue, Jun 09, 2020 at 06:51:28PM +0900, Jaewon Kim wrote: >>

Re: [PATCH] page_alloc: consider highatomic reserve in wmartermark fast

On 2020년 06월 10일 10:21, Minchan Kim wrote: > Hi Jaewon, > > On Tue, Jun 09, 2020 at 06:51:28PM +0900, Jaewon Kim wrote: >> zone_watermark_fast was introduced by commit 48ee5f3696f6 ("mm, >> page_alloc: shortcut watermark checks for order-0 pages"). The commit

Re: [PATCH] page_alloc: consider highatomic reserve in wmartermark fast

fine, I simply wanted to illustrate where I thought the check > should go to minimise the impact to the majority of allocations. Hello Mel. Can I understand that you also agrees on checking highatomic reserved? Additionally I've wondered why the number of highatomic free pages is not accurately counted like cma free. Is there any concern on counting it? > Thank you Jaewon Kim

[PATCH] page_alloc: consider highatomic reserve in wmartermark fast

reclaimable? no <4>[ 156.701738] [4:kswapd0: 1209] Normal free:9956kB min:7428kB low:93440kB high:97032kB active_anon:355176kB inactive_anon:354580kB active_file:396196kB inactive_file:677284kB unevictable:193168kB writepending:2304kB present:4081664kB managed:3593324kB mlocked:

Re: [PATCH] of/platform: Support dynamic device tree on AMBA bus

On 11/1/18 1:06 AM, Frank Rowand wrote: On 10/31/18 8:32 AM, Jaewon Kim wrote: Hi Frank, Thanks to review my patch. On 18. 10. 31. 오전 8:04, Frank Rowand wrote: Hi Jaewon, On 10/25/18 9:39 AM, Jaewon Kim wrote: This patch supports dynamic device-tree for AMBA device. Add AMBA devices

Re: [PATCH] of/platform: Support dynamic device tree on AMBA bus

On 11/1/18 1:06 AM, Frank Rowand wrote: On 10/31/18 8:32 AM, Jaewon Kim wrote: Hi Frank, Thanks to review my patch. On 18. 10. 31. 오전 8:04, Frank Rowand wrote: Hi Jaewon, On 10/25/18 9:39 AM, Jaewon Kim wrote: This patch supports dynamic device-tree for AMBA device. Add AMBA devices

Re: [PATCH] of/platform: Support dynamic device tree on AMBA bus

Hi Frank, Thanks to review my patch. On 18. 10. 31. 오전 8:04, Frank Rowand wrote: Hi Jaewon, On 10/25/18 9:39 AM, Jaewon Kim wrote: This patch supports dynamic device-tree for AMBA device. Add AMBA devices and buses to of_platform_notify() so that dynamic device-tree will support AMBA

Re: [PATCH] of/platform: Support dynamic device tree on AMBA bus

Hi Frank, Thanks to review my patch. On 18. 10. 31. 오전 8:04, Frank Rowand wrote: Hi Jaewon, On 10/25/18 9:39 AM, Jaewon Kim wrote: This patch supports dynamic device-tree for AMBA device. Add AMBA devices and buses to of_platform_notify() so that dynamic device-tree will support AMBA

Re: [PATCH] spi: dw: fix buffer end address

There is some side effect on this patch. So, I revoke this patch. 18. 10. 25. 오전 12:37에 Jaewon Kim 이(가) 쓴 글: Buffer address can be NULL, if user does not want to receive TX/RX data. In this case, driver should not set the rx/tx_end value with len. Signed-off-by: Jaewon Kim --- drivers/spi

Re: [PATCH] spi: dw: fix buffer end address

There is some side effect on this patch. So, I revoke this patch. 18. 10. 25. 오전 12:37에 Jaewon Kim 이(가) 쓴 글: Buffer address can be NULL, if user does not want to receive TX/RX data. In this case, driver should not set the rx/tx_end value with len. Signed-off-by: Jaewon Kim --- drivers/spi

[PATCH] of/platform: Support dynamic device tree on AMBA bus

This patch supports dynamic device-tree for AMBA device. The AMBA device must be registered on the AMBA bus, not the platform bus. Signed-off-by: Jaewon Kim --- drivers/of/platform.c | 93 --- 1 file changed, 73 insertions(+), 20 deletions

[PATCH] of/platform: Support dynamic device tree on AMBA bus

This patch supports dynamic device-tree for AMBA device. The AMBA device must be registered on the AMBA bus, not the platform bus. Signed-off-by: Jaewon Kim --- drivers/of/platform.c | 93 --- 1 file changed, 73 insertions(+), 20 deletions

[PATCH] spi: dw: fix buffer end address

Buffer address can be NULL, if user does not want to receive TX/RX data. In this case, driver should not set the rx/tx_end value with len. Signed-off-by: Jaewon Kim --- drivers/spi/spi-dw.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/spi/spi-dw.c b

[PATCH] spi: dw: fix buffer end address

Buffer address can be NULL, if user does not want to receive TX/RX data. In this case, driver should not set the rx/tx_end value with len. Signed-off-by: Jaewon Kim --- drivers/spi/spi-dw.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/spi/spi-dw.c b

[PATCH] drivers: of: of_reserved_mem: detect count overflow or range overlap

+0x1e0/0x404 <4>[2.309751] [2: swapper/0:1] [] check_reserved_mem+0x4c/0x50 <4>[2.309802] [2: swapper/0:1] [] do_one_initcall+0x54/0x214 <4>[2.309856] [2: swapper/0:1] [] kernel_init_freeable+0x198/0x24c <4>[2.309913] [2

[PATCH] drivers: of: of_reserved_mem: detect count overflow or range overlap

+0x1e0/0x404 <4>[2.309751] [2: swapper/0:1] [] check_reserved_mem+0x4c/0x50 <4>[2.309802] [2: swapper/0:1] [] do_one_initcall+0x54/0x214 <4>[2.309856] [2: swapper/0:1] [] kernel_init_freeable+0x198/0x24c <4>[2.309913] [2

Re: [RFC v2] dma-coherent: introduce no-align to avoid allocation failure and save memory

Hello 2017-11-24 19:35 GMT+09:00 David Laight <david.lai...@aculab.com>: > From: Jaewon Kim >> Sent: 24 November 2017 05:59 >> >> dma-coherent uses bitmap APIs which internally consider align based on the >> requested size. If most of allocations are small size li

Re: [RFC v2] dma-coherent: introduce no-align to avoid allocation failure and save memory

Hello 2017-11-24 19:35 GMT+09:00 David Laight : > From: Jaewon Kim >> Sent: 24 November 2017 05:59 >> >> dma-coherent uses bitmap APIs which internally consider align based on the >> requested size. If most of allocations are small size like KBs, using >>

[RFC v2] dma-coherent: introduce no-align to avoid allocation failure and save memory

than forcely using no-align Signed-off-by: Jaewon Kim <jaewon31@samsung.com> --- .../bindings/reserved-memory/reserved-memory.txt | 6 +++ arch/arm/mm/dma-mapping-nommu.c| 3 +- drivers/base/dma-coherent.c| 49 -- i

[RFC v2] dma-coherent: introduce no-align to avoid allocation failure and save memory

than forcely using no-align Signed-off-by: Jaewon Kim --- .../bindings/reserved-memory/reserved-memory.txt | 6 +++ arch/arm/mm/dma-mapping-nommu.c| 3 +- drivers/base/dma-coherent.c| 49 -- include/linux/dma-mapping.h

Re: [RFC PATCH] drivers: base: dma-coherent: find free region without alignment

Hello Marek On 2017년 11월 14일 20:07, Marek Szyprowski wrote: > Hi Jaewon, > > On 2017-11-14 09:42, Jaewon Kim wrote: >> dma-coherent uses bitmap API which internally consider align based on the >> requested size. Depending on some usage pattern, using align, I think, may >&

Re: [RFC PATCH] drivers: base: dma-coherent: find free region without alignment

Hello Marek On 2017년 11월 14일 20:07, Marek Szyprowski wrote: > Hi Jaewon, > > On 2017-11-14 09:42, Jaewon Kim wrote: >> dma-coherent uses bitmap API which internally consider align based on the >> requested size. Depending on some usage pattern, using align, I think, may >&

[RFC PATCH] drivers: base: dma-coherent: find free region without alignment

removes the align policy to allow allocation without increasing the total size. Signed-off-by: Jaewon Kim <jaewon31@samsung.com> --- drivers/base/dma-coherent.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-cohe

[RFC PATCH] drivers: base: dma-coherent: find free region without alignment

removes the align policy to allow allocation without increasing the total size. Signed-off-by: Jaewon Kim --- drivers/base/dma-coherent.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c index 744f64f43454

Re: [PATCH] mm: page_ext: allocate page extension though first PFN is invalid

2017-11-08 16:52 GMT+09:00 Joonsoo Kim <iamjoonsoo@lge.com>: > On Tue, Nov 07, 2017 at 06:44:47PM +0900, Jaewon Kim wrote: >> online_page_ext and page_ext_init allocate page_ext for each section, but >> they do not allocate if the first PFN is !pfn_present(pfn)

Re: [PATCH] mm: page_ext: allocate page extension though first PFN is invalid

2017-11-08 16:52 GMT+09:00 Joonsoo Kim : > On Tue, Nov 07, 2017 at 06:44:47PM +0900, Jaewon Kim wrote: >> online_page_ext and page_ext_init allocate page_ext for each section, but >> they do not allocate if the first PFN is !pfn_present(pfn) or >> !pfn_valid(pfn). >&g

[PATCH] mm: page_ext: check if page_ext is not prepared

3c/0x58 <4>[ 11.626305] [] __do_fault+0x80/0x120 <4>[ 11.626347] [] handle_mm_fault+0x704/0xbb0 <4>[ 11.626393] [] do_page_fault+0x2e8/0x394 <4>[ 11.626437] [] do_mem_abort+0x88/0x124 Signed-off-by: Jaewon Kim <jaewon31@samsung.com> --- mm/page_ext.c |

[PATCH] mm: page_ext: check if page_ext is not prepared

3c/0x58 <4>[ 11.626305] [] __do_fault+0x80/0x120 <4>[ 11.626347] [] handle_mm_fault+0x704/0xbb0 <4>[ 11.626393] [] do_page_fault+0x2e8/0x394 <4>[ 11.626437] [] do_mem_abort+0x88/0x124 Signed-off-by: Jaewon Kim --- mm/page_ext.c | 4 1 file changed, 4 deletions(

[PATCH] mm: page_ext: allocate page extension though first PFN is invalid

consuming job. Let's check each (section count / 16) PFN, then prepare page_ext if any PFN is present or valid. Signed-off-by: Jaewon Kim <jaewon31@samsung.com> --- mm/page_ext.c | 25 ++--- 1 file changed, 22 insertions(+), 3 deletions(-) diff --git a/mm/page_ext.

[PATCH] mm: page_ext: allocate page extension though first PFN is invalid

consuming job. Let's check each (section count / 16) PFN, then prepare page_ext if any PFN is present or valid. Signed-off-by: Jaewon Kim --- mm/page_ext.c | 25 ++--- 1 file changed, 22 insertions(+), 3 deletions(-) diff --git a/mm/page_ext.c b/mm/page_ext.c index 32f18911deda

Re: [PATCH] mm: page_ext: allocate page extension though first PFN is invalid

2017-11-02 17:02 GMT+09:00 Michal Hocko <mho...@kernel.org>: > On Thu 02-11-17 15:35:07, Jaewon Kim wrote: >> online_page_ext and page_ext_init allocate page_ext for each section, but >> they do not allocate if the first PFN is !pfn_present(pfn) or >> !pfn_valid(p

Re: [PATCH] mm: page_ext: allocate page extension though first PFN is invalid

2017-11-02 17:02 GMT+09:00 Michal Hocko : > On Thu 02-11-17 15:35:07, Jaewon Kim wrote: >> online_page_ext and page_ext_init allocate page_ext for each section, but >> they do not allocate if the first PFN is !pfn_present(pfn) or >> !pfn_valid(pfn). Then section->

[PATCH] mm: page_ext: allocate page extension though first PFN is invalid

nt / 16) PFN, then prepare page_ext if any PFN is present or valid. And remove the CONFIG_DEBUG_VM in lookup_page_ext to avoid panic. Signed-off-by: Jaewon Kim <jaewon31@samsung.com> --- mm/page_ext.c | 29 ++--- 1 file changed, 22 insertions(+), 7 deletions(-)

[PATCH] mm: page_ext: allocate page extension though first PFN is invalid

nt / 16) PFN, then prepare page_ext if any PFN is present or valid. And remove the CONFIG_DEBUG_VM in lookup_page_ext to avoid panic. Signed-off-by: Jaewon Kim --- mm/page_ext.c | 29 ++--- 1 file changed, 22 insertions(+), 7 deletions(-) diff --git a/mm/page_ext.c b/mm/

[PATCH v2] mm: cma: print allocation failure reason and bitmap status

available pages at 572 position starting from 0 position. [ 12.415503] [2: Binder:714_1: 744] cma: number of available pages: 4@572+7@585+7@601+8@632+38@730+166@1114+127@1921=> 357 free of 2048 total pages Signed-off-by: Jaewon Kim <jaewon31@samsung.com> Acked-by: Michal Nazare

[PATCH v2] mm: cma: print allocation failure reason and bitmap status

available pages at 572 position starting from 0 position. [ 12.415503] [2: Binder:714_1: 744] cma: number of available pages: 4@572+7@585+7@601+8@632+38@730+166@1114+127@1921=> 357 free of 2048 total pages Signed-off-by: Jaewon Kim Acked-by: Michal Nazarewicz --- mm/cma.c |

Re: [PATCH] lib: bitmap: introduce bitmap_find_next_zero_area_and_size

On 2017년 01월 15일 16:17, Yury Norov wrote: > Hi Jaewon, > > with all comments above, some of my concerns. > > On Mon, Dec 26, 2016 at 01:18:11PM +0900, Jaewon Kim wrote: >> There was no bitmap API which returns both next zero index and size of zeros >> from that i

Re: [PATCH] lib: bitmap: introduce bitmap_find_next_zero_area_and_size

On 2017년 01월 15일 16:17, Yury Norov wrote: > Hi Jaewon, > > with all comments above, some of my concerns. > > On Mon, Dec 26, 2016 at 01:18:11PM +0900, Jaewon Kim wrote: >> There was no bitmap API which returns both next zero index and size of zeros >> from that i

Re: [PATCH] mm: cma: print allocation failure reason and bitmap status

On 2017년 01월 02일 15:46, Michal Nazarewicz wrote: > On Mon, Jan 02 2017, Jaewon Kim wrote: >> There are many reasons of CMA allocation failure such as EBUSY, ENOMEM, >> EINTR. >> But we did not know error reason so far. This patch prints the error value. >> >>

Re: [PATCH] mm: cma: print allocation failure reason and bitmap status

On 2017년 01월 02일 15:46, Michal Nazarewicz wrote: > On Mon, Jan 02 2017, Jaewon Kim wrote: >> There are many reasons of CMA allocation failure such as EBUSY, ENOMEM, >> EINTR. >> But we did not know error reason so far. This patch prints the error value. >> >>

Re: [PATCH] mm: cma: print allocation failure reason and bitmap status

On 2017년 01월 02일 06:59, Michal Nazarewicz wrote: > On Fri, Dec 30 2016, Michal Hocko wrote: >> On Fri 30-12-16 16:24:46, Jaewon Kim wrote: >> [...] >>> >From 7577cc94da3af27907aa6eec590d2ef51e4b9d80 Mon Sep 17 00:00:00 2001 >>> From: Jaewon Kim <jaewon31

Re: [PATCH] mm: cma: print allocation failure reason and bitmap status

On 2017년 01월 02일 06:59, Michal Nazarewicz wrote: > On Fri, Dec 30 2016, Michal Hocko wrote: >> On Fri 30-12-16 16:24:46, Jaewon Kim wrote: >> [...] >>> >From 7577cc94da3af27907aa6eec590d2ef51e4b9d80 Mon Sep 17 00:00:00 2001 >>> From: Jaewon Kim >&

Re: [PATCH] mm: cma: print allocation failure reason and bitmap status

Hello Michal Hocko and and Michal Nazarewichz On 2016년 12월 29일 23:20, Michal Nazarewicz wrote: > On Thu, Dec 29 2016, Michal Hocko wrote: >> On Thu 29-12-16 11:28:02, Jaewon Kim wrote: >>> There are many reasons of CMA allocation failure such as EBUSY, ENOMEM, >>> E

Re: [PATCH] mm: cma: print allocation failure reason and bitmap status

Hello Michal Hocko and and Michal Nazarewichz On 2016년 12월 29일 23:20, Michal Nazarewicz wrote: > On Thu, Dec 29 2016, Michal Hocko wrote: >> On Thu 29-12-16 11:28:02, Jaewon Kim wrote: >>> There are many reasons of CMA allocation failure such as EBUSY, ENOMEM, >>> E

Re: [PATCH] mm: cma: print allocation failure reason and bitmap status

On 2016년 12월 29일 18:43, Michal Hocko wrote: > On Thu 29-12-16 18:26:38, Jaewon Kim wrote: >> >> On 2016년 12월 29일 18:14, Michal Hocko wrote: >>> On Thu 29-12-16 11:28:02, Jaewon Kim wrote: >>>> There are many reasons of CMA allocation failure such as EBUSY,

Re: [PATCH] mm: cma: print allocation failure reason and bitmap status

On 2016년 12월 29일 18:43, Michal Hocko wrote: > On Thu 29-12-16 18:26:38, Jaewon Kim wrote: >> >> On 2016년 12월 29일 18:14, Michal Hocko wrote: >>> On Thu 29-12-16 11:28:02, Jaewon Kim wrote: >>>> There are many reasons of CMA allocation failure such as EBUSY,

Re: [PATCH] mm: cma: print allocation failure reason and bitmap status

On 2016년 12월 29일 18:14, Michal Hocko wrote: > On Thu 29-12-16 11:28:02, Jaewon Kim wrote: >> There are many reasons of CMA allocation failure such as EBUSY, ENOMEM, >> EINTR. >> This patch prints the error value and bitmap status to know available pages >&

Re: [PATCH] mm: cma: print allocation failure reason and bitmap status

On 2016년 12월 29일 18:14, Michal Hocko wrote: > On Thu 29-12-16 11:28:02, Jaewon Kim wrote: >> There are many reasons of CMA allocation failure such as EBUSY, ENOMEM, >> EINTR. >> This patch prints the error value and bitmap status to know available pages >&

[PATCH] mm: cma: print allocation failure reason and bitmap status

, req-size: 256 pages, ret: -12 [ 11.616365] [2: Binder:711_1: 740] number of available pages: 4+7+7+8+38+166+127=>357 pages, total: 2048 pages Signed-off-by: Jaewon Kim <jaewon31@samsung.com> --- mm/cma.c | 29 - 1 file changed, 28 insertions(+), 1

[PATCH] mm: cma: print allocation failure reason and bitmap status

, req-size: 256 pages, ret: -12 [ 11.616365] [2: Binder:711_1: 740] number of available pages: 4+7+7+8+38+166+127=>357 pages, total: 2048 pages Signed-off-by: Jaewon Kim --- mm/cma.c | 29 - 1 file changed, 28 insertions(+), 1 deletion(-) diff --git a/mm/cma.

Re: [PATCH] lib: bitmap: introduce bitmap_find_next_zero_area_and_size

: > On Wed, Dec 28 2016, Jaewon Kim wrote: >> I did not add caller in this patch. >> I am using the patch in cma_alloc function like below to show >> available page status. >> >> + printk("number of available p

Re: [PATCH] lib: bitmap: introduce bitmap_find_next_zero_area_and_size

: > On Wed, Dec 28 2016, Jaewon Kim wrote: >> I did not add caller in this patch. >> I am using the patch in cma_alloc function like below to show >> available page status. >> >> + printk("number of available p

Re: [PATCH] lib: bitmap: introduce bitmap_find_next_zero_area_and_size

On 2016년 12월 27일 19:05, Michal Hocko wrote: > On Mon 26-12-16 13:18:11, Jaewon Kim wrote: >> There was no bitmap API which returns both next zero index and size of zeros >> from that index. >> >> This is helpful to look fragmentation. This is an test code to look

Re: [PATCH] lib: bitmap: introduce bitmap_find_next_zero_area_and_size

On 2016년 12월 27일 19:05, Michal Hocko wrote: > On Mon 26-12-16 13:18:11, Jaewon Kim wrote: >> There was no bitmap API which returns both next zero index and size of zeros >> from that index. >> >> This is helpful to look fragmentation. This is an test code to look

Re: [PATCH] lib: bitmap: introduce bitmap_find_next_zero_area_and_size

On 2016년 12월 27일 06:09, Michal Nazarewicz wrote: > On Mon, Dec 26 2016, Jaewon Kim wrote: >> There was no bitmap API which returns both next zero index and size of zeros >> from that index. > Is it really needed? Does it noticeably simplifies callers? Why can’t >

Re: [PATCH] lib: bitmap: introduce bitmap_find_next_zero_area_and_size

On 2016년 12월 27일 06:09, Michal Nazarewicz wrote: > On Mon, Dec 26 2016, Jaewon Kim wrote: >> There was no bitmap API which returns both next zero index and size of zeros >> from that index. > Is it really needed? Does it noticeably simplifies callers? Why can’t >

[PATCH] lib: bitmap: introduce bitmap_find_next_zero_area_and_size

printk("+%u", nr_found); nr_found_tot += nr_found; search_idx = found_idx + nr_found; } printk("=>%lu found of total: %lu\n", nr_found_tot, bitmap_max); Signed-off-by: Jaewon Kim <jaewon31@samsung.com> --- include/linux/bitm

[PATCH] lib: bitmap: introduce bitmap_find_next_zero_area_and_size

printk("+%u", nr_found); nr_found_tot += nr_found; search_idx = found_idx + nr_found; } printk("=>%lu found of total: %lu\n", nr_found_tot, bitmap_max); Signed-off-by: Jaewon Kim --- include/linux/bitmap.h | 6 ++ lib/bitmap.c | 25 +++

Re: [PATCH] staging: android: ion: return -ENOMEM in ion_cma_heap allocation failure

2016-12-14 1:04 GMT+09:00 Laura Abbott <labb...@redhat.com>: > On 12/08/2016 09:05 PM, Jaewon Kim wrote: >> Initial Commit 349c9e138551 ("gpu: ion: add CMA heap") returns -1 in >> allocation >> failure. The returned value is passed up to userspace through io

Re: [PATCH] staging: android: ion: return -ENOMEM in ion_cma_heap allocation failure

2016-12-14 1:04 GMT+09:00 Laura Abbott : > On 12/08/2016 09:05 PM, Jaewon Kim wrote: >> Initial Commit 349c9e138551 ("gpu: ion: add CMA heap") returns -1 in >> allocation >> failure. The returned value is passed up to userspace through ioctl. So user >&

[PATCH] staging: android: ion: return -ENOMEM in ion_cma_heap allocation failure

Signed-off-by: Jaewon Kim <jaewon31@samsung.com> --- drivers/staging/android/ion/ion_cma_heap.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/staging/android/ion/ion_cma_heap.c b/drivers/staging/android/ion/ion_cma_heap.c index 6c7de74..22b9582 100644 --- a

[PATCH] staging: android: ion: return -ENOMEM in ion_cma_heap allocation failure

Signed-off-by: Jaewon Kim --- drivers/staging/android/ion/ion_cma_heap.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/staging/android/ion/ion_cma_heap.c b/drivers/staging/android/ion/ion_cma_heap.c index 6c7de74..22b9582 100644 --- a/drivers/staging/android/ion/ion_

[PATCH] [RFC] drivers: dma-coherent: pass struct dma_attrs to dma_alloc_from_coherent

ZEROING could be skipped or could be done later. Signed-off-by: Jaewon Kim <jaewon31@samsung.com> --- drivers/base/dma-coherent.c | 6 +- include/linux/dma-mapping.h | 7 --- 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/base/dma-coherent.c b/drivers/ba

[PATCH] [RFC] drivers: dma-coherent: pass struct dma_attrs to dma_alloc_from_coherent

ZEROING could be skipped or could be done later. Signed-off-by: Jaewon Kim --- drivers/base/dma-coherent.c | 6 +- include/linux/dma-mapping.h | 7 --- 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c index 640a7e6

Re: [PATCH] [RFC] drivers: dma-coherent: use MEMREMAP_WB instead of MEMREMAP_WC

-by: Jaewon Kim <jaewon31@samsung.com> --- drivers/base/dma-coherent.c | 6 +- include/linux/dma-mapping.h | 7 --- 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c index 640a7e6..428eced 100644 --- a/driver

Re: [PATCH] [RFC] drivers: dma-coherent: use MEMREMAP_WB instead of MEMREMAP_WC

-by: Jaewon Kim --- drivers/base/dma-coherent.c | 6 +- include/linux/dma-mapping.h | 7 --- 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c index 640a7e6..428eced 100644 --- a/drivers/base/dma-coherent.c +++ b

Re: [PATCH] [RFC] drivers: dma-coherent: use MEMREMAP_WB instead of MEMREMAP_WC

Hi On 2016년 11월 10일 18:51, Brian Starkey wrote: > Hi Jaewon, > > On Thu, Nov 10, 2016 at 10:41:43AM +0900, Jaewon Kim wrote: >> Hi >> >> On 2016년 11월 09일 19:23, Brian Starkey wrote: >>> Hi, >>> >>> On Wed, Nov 09, 2016 at 06:47:26PM +0900, J

Re: [PATCH] [RFC] drivers: dma-coherent: use MEMREMAP_WB instead of MEMREMAP_WC

Hi On 2016년 11월 10일 18:51, Brian Starkey wrote: > Hi Jaewon, > > On Thu, Nov 10, 2016 at 10:41:43AM +0900, Jaewon Kim wrote: >> Hi >> >> On 2016년 11월 09일 19:23, Brian Starkey wrote: >>> Hi, >>> >>> On Wed, Nov 09, 2016 at 06:47:26PM +0900, J

Re: [PATCH] [RFC] drivers: dma-coherent: use MEMREMAP_WB instead of MEMREMAP_WC

Hi On 2016년 11월 09일 19:23, Brian Starkey wrote: > Hi, > > On Wed, Nov 09, 2016 at 06:47:26PM +0900, Jaewon Kim wrote: >> >> >> On 2016년 11월 09일 18:27, Brian Starkey wrote: >>> Hi Jaewon, >>> >>> On Wed, Nov 09, 2016 at 06:10:09PM +0900, Ja

Re: [PATCH] [RFC] drivers: dma-coherent: use MEMREMAP_WB instead of MEMREMAP_WC

Hi On 2016년 11월 09일 19:23, Brian Starkey wrote: > Hi, > > On Wed, Nov 09, 2016 at 06:47:26PM +0900, Jaewon Kim wrote: >> >> >> On 2016년 11월 09일 18:27, Brian Starkey wrote: >>> Hi Jaewon, >>> >>> On Wed, Nov 09, 2016 at 06:10:09PM +0900, Ja

Re: [PATCH] [RFC] drivers: dma-coherent: use MEMREMAP_WB instead of MEMREMAP_WC

On 2016년 11월 09일 18:27, Brian Starkey wrote: > Hi Jaewon, > > On Wed, Nov 09, 2016 at 06:10:09PM +0900, Jaewon Kim wrote: >> Commit 6b03ae0d42bf (drivers: dma-coherent: use MEMREMAP_WC for >> DMA_MEMORY_MA) >> added MEMREMAP_WC for DMA_MEMORY_MAP. If, how

Re: [PATCH] [RFC] drivers: dma-coherent: use MEMREMAP_WB instead of MEMREMAP_WC

On 2016년 11월 09일 18:27, Brian Starkey wrote: > Hi Jaewon, > > On Wed, Nov 09, 2016 at 06:10:09PM +0900, Jaewon Kim wrote: >> Commit 6b03ae0d42bf (drivers: dma-coherent: use MEMREMAP_WC for >> DMA_MEMORY_MA) >> added MEMREMAP_WC for DMA_MEMORY_MAP. If, how

[PATCH] [RFC] drivers: dma-coherent: use MEMREMAP_WB instead of MEMREMAP_WC

Signed-off-by: Jaewon Kim <jaewon31@samsung.com> --- drivers/base/dma-coherent.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c index 640a7e6..0512a1d 100644 --- a/drivers/base/dma-coherent.c +++ b/drivers/ba

[PATCH] [RFC] drivers: dma-coherent: use MEMREMAP_WB instead of MEMREMAP_WC

Signed-off-by: Jaewon Kim --- drivers/base/dma-coherent.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c index 640a7e6..0512a1d 100644 --- a/drivers/base/dma-coherent.c +++ b/drivers/base/dma-coherent.c @@ -33,7 +33,7

[PATCH] usb: host: max3421-hcd: fix mask of IO control register

GPIO control register is divided into IOPINS1 and IOPINS2. And low 4-bit of register is controls output. So, this patch fixes wrong mask of GPIO output. Signed-off-by: Jaewon Kim <jaewon02@samsung.com> --- drivers/usb/host/max3421-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 de

[PATCH] usb: host: max3421-hcd: fix mask of IO control register

GPIO control register is divided into IOPINS1 and IOPINS2. And low 4-bit of register is controls output. So, this patch fixes wrong mask of GPIO output. Signed-off-by: Jaewon Kim --- drivers/usb/host/max3421-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb

Re: Re: [RESEND][PATCH] drivers: of: of_reserved_mem: fixup the CMA alignment not to affect dma-coherent

mmit considers not only dma-contiguous(CMA) but also >> dma-coherent which has no that requirement. >> >> This patch checks more to distinguish dma-contiguous(CMA) from dma-coherent. >> >> Signed-off-by: Jaewon Kim <jaewon31@samsung.com> >> --- >>

Re: Re: [RESEND][PATCH] drivers: of: of_reserved_mem: fixup the CMA alignment not to affect dma-coherent

iguous(CMA) but also >> dma-coherent which has no that requirement. >> >> This patch checks more to distinguish dma-contiguous(CMA) from dma-coherent. >> >> Signed-off-by: Jaewon Kim >> --- >> drivers/of/of_reserved_mem.c | 5 - >> 1 file cha

Re: Re: [RESEND][PATCH] drivers: of: of_reserved_mem: fixup the CMA alignment not to affect dma-coherent

>Hello, > > >On 2016-05-25 16:38, Rob Herring wrote: >> On Tue, May 24, 2016 at 11:29 PM, Jaewon Kim <jaewon31@samsung.com> >> wrote: >>> From: Jaewon <jaewon31@samsung.com> >>> >>> There was an alignment mismatch issu

Re: Re: [RESEND][PATCH] drivers: of: of_reserved_mem: fixup the CMA alignment not to affect dma-coherent

>Hello, > > >On 2016-05-25 16:38, Rob Herring wrote: >> On Tue, May 24, 2016 at 11:29 PM, Jaewon Kim >> wrote: >>> From: Jaewon >>> >>> There was an alignment mismatch issue for CMA and it was fixed by >>> commit 1cc8e3458b51 (&quo

[RESEND][PATCH] drivers: of: of_reserved_mem: fixup the CMA alignment not to affect dma-coherent

herent which has no that requirement. This patch checks more to distinguish dma-contiguous(CMA) from dma-coherent. Signed-off-by: Jaewon Kim <jaewon31@samsung.com> --- drivers/of/of_reserved_mem.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/of/of_re

[RESEND][PATCH] drivers: of: of_reserved_mem: fixup the CMA alignment not to affect dma-coherent

equirement. This patch checks more to distinguish dma-contiguous(CMA) from dma-coherent. Signed-off-by: Jaewon Kim --- drivers/of/of_reserved_mem.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c index ed01c01..45b8

[PATCH] drivers: of: of_reserved_mem: fixup the CMA alignment not to affect dma-coherent

There was an alignment mismatch issue for CMA and it was fixed by commit 1cc8e3458b51 ("drivers: of: of_reserved_mem: fixup the alignment with CMA setup"). However the way of the commit considers not only dma-contiguous(CMA) but also dma-coherent which has no that requirement. This patch checks

[PATCH] drivers: of: of_reserved_mem: fixup the CMA alignment not to affect dma-coherent

There was an alignment mismatch issue for CMA and it was fixed by commit 1cc8e3458b51 ("drivers: of: of_reserved_mem: fixup the alignment with CMA setup"). However the way of the commit considers not only dma-contiguous(CMA) but also dma-coherent which has no that requirement. This patch checks

Re: [PATCH v2] vmscan: fix increasing nr_isolated incurred by putback unevictable pages

On 2015년 08월 05일 08:31, Minchan Kim wrote: > Hello, > > On Tue, Aug 04, 2015 at 03:09:37PM -0700, Andrew Morton wrote: >> On Tue, 04 Aug 2015 19:40:08 +0900 Jaewon Kim >> wrote: >> >>> reclaim_clean_pages_from_list() assumes that shrink_page_list() retu

[PATCH v2] vmscan: fix increasing nr_isolated incurred by putback unevictable pages

changes shrink_page_list() to pass unevictable pages back to caller. Caller will take care those pages. Signed-off-by: Jaewon Kim --- Changes since v1 1/ changed subject from vmscan: reclaim_clean_pages_from_list() must count mlocked pages 2/ changed to return unevictable pages rather than

  1   2   3   4   5   >