[PATCH v2] mm: fix a race on nr_swap_pages

nr_swap_pages = -1 Signed-off-by: Zhaoyang Huang --- change of v2: fix bug of unpaired of spin_lock --- --- mm/swapfile.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/mm/swapfile.c b/mm/swapfile.c index cf63b5f..1212f17 100644 --- a/mm/swapfile.c +++ b/mm/

Re: [PATCH] mm: fix a race on nr_swap_pages

It is show_swap_cache_info() which races with get_swap_xxx On Thu, Dec 3, 2020 at 7:36 PM Zhaoyang Huang wrote: > > The scenario on which "Free swap -4kB" happens in my system, which is caused > by > get_swap_page_of_type or get_swap_pages racing with show_mem. R

[PATCH] mm: fix a race on nr_swap_pages

The scenario on which "Free swap -4kB" happens in my system, which is caused by get_swap_page_of_type or get_swap_pages racing with show_mem. Remove the race here. Signed-off-by: Zhaoyang Huang --- mm/swapfile.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff

[RFC PATCH] mm: bail out from psi memstall when cond_resched

Memory reclaiming will run as several seconds in memory constraint system, which will be deemed as heavy memstall. Have the memory reclaim be more presiced by bailing out when cond_resched Signed-off-by: Zhaoyang Huang --- mm/vmscan.c | 23 --- 1 file changed, 16 insertions

Re: [PATCH v2] mm : sync ra->ra_pages with bdi->ra_pages

On Fri, Aug 21, 2020 at 7:57 PM Matthew Wilcox wrote: > > On Fri, Aug 21, 2020 at 05:31:52PM +0800, Zhaoyang Huang wrote: > > This patch has been verified on an android system and reduces 15% of > > UNITERRUPTIBLE_SLEEP_BLOCKIO which was used to be caused by wrong > > ra-&

Re: [PATCH v2] mm : sync ra->ra_pages with bdi->ra_pages

On Fri, Aug 21, 2020 at 7:57 PM Matthew Wilcox wrote: > > On Fri, Aug 21, 2020 at 05:31:52PM +0800, Zhaoyang Huang wrote: > > This patch has been verified on an android system and reduces 15% of > > UNITERRUPTIBLE_SLEEP_BLOCKIO which was used to be caused by wrong > > ra-&

Re: [PATCH v2] mm : sync ra->ra_pages with bdi->ra_pages

On Fri, Aug 21, 2020 at 5:24 PM Zhaoyang Huang wrote: > > Some system(like android) will turbo read during startup via expanding the > readahead window and then set it back to normal(128kb as usual). However, some > files in the system process context will keep to be opened since

[PATCH v2] mm : sync ra->ra_pages with bdi->ra_pages

above two cases. Signed-off-by: Zhaoyang Huang --- change from v2: fix checkpatch error --- --- include/linux/fs.h | 17 + mm/fadvise.c | 4 +++- mm/filemap.c | 19 +-- mm/readahead.c | 37 + 4 files chang

Re: [PATCH] mm : sync ra->ra_pages with bdi->ra_pages

On Fri, Aug 14, 2020 at 5:03 PM Zhaoyang Huang wrote: > > Some system(like android) will turbo read during startup via expanding the > readahead window and then set it back to normal(128kb as usual). However, some > files in the system process context will keep to be opened since

Re: [PATCH] mm : sync ra->ra_pages with bdi->ra_pages

On Sat, Aug 15, 2020 at 12:15 PM Andrew Morton wrote: > > On Fri, 14 Aug 2020 13:10:34 -0700 Andrew Morton > wrote: > > > On Fri, 14 Aug 2020 17:03:44 +0800 Zhaoyang Huang > > wrote: > > > > > Some system(like android) will turbo read during startup v

[PATCH] mm : sync ra->ra_pages with bdi->ra_pages

above two cases. Signed-off-by: Zhaoyang Huang --- include/linux/fs.h | 17 + mm/fadvise.c | 4 +++- mm/filemap.c | 19 +-- mm/readahead.c | 38 ++ 4 files changed, 67 insertions(+), 11 deletions(-) diff --git a/i

Re: [PATCH] mm : update ra->ra_pages if it's NOT equal to bdi->ra_pages

On Fri, Aug 14, 2020 at 10:33 AM Andrew Morton wrote: > > On Fri, 14 Aug 2020 10:20:11 +0800 Zhaoyang Huang > wrote: > > > On Fri, Aug 14, 2020 at 10:07 AM Matthew Wilcox wrote: > > > > > > On Fri, Aug 14, 2020 at 02:43:55AM +0100, Matthew Wilcox wrote: &

Re: [PATCH] mm : update ra->ra_pages if it's NOT equal to bdi->ra_pages

On Fri, Aug 14, 2020 at 10:20 AM Zhaoyang Huang wrote: > > On Fri, Aug 14, 2020 at 10:07 AM Matthew Wilcox wrote: > > > > On Fri, Aug 14, 2020 at 02:43:55AM +0100, Matthew Wilcox wrote: > > > On Fri, Aug 14, 2020 at 09:30:11AM +0800, Zhaoyang Huang wrote: > > >

Re: [PATCH] mm : update ra->ra_pages if it's NOT equal to bdi->ra_pages

On Fri, Aug 14, 2020 at 10:07 AM Matthew Wilcox wrote: > > On Fri, Aug 14, 2020 at 02:43:55AM +0100, Matthew Wilcox wrote: > > On Fri, Aug 14, 2020 at 09:30:11AM +0800, Zhaoyang Huang wrote: > > > file->f_ra->ra_pages will remain the initialized value since

[PATCH] mm : update ra->ra_pages if it's NOT equal to bdi->ra_pages

file->f_ra->ra_pages will remain the initialized value since it opend, which may be NOT equal to bdi->ra_pages as the latter one is updated somehow(etc, echo xxx > /sys/block/dm/queue/read_ahead_kb).So sync ra->ra_pages to the updated value when sync read. Signed-off-by: Zhaoyang

[RFC PATCH] mm : using bdi->ra_pages instead of ra->ra_pages within readahead

file->f_ra->ra_pages will remain the initialized value since it opend, which may be NOT equal to bdi->ra_pages as the latter one is updated somehow(etc, echo xxx > /sys/block/dm/queue/read_ahead_kb).So having readahead use bdi->ra_pages. Signed-off-by: Zhaoyang Huang --- m

[PATCH v2] trace : use kvzalloc instead of kzalloc

) (vfs_open) from [] (path_openat+0x5fc/0x169c) (path_openat) from [] (do_filp_open+0x94/0xf8) (do_filp_open) from [] (do_sys_open+0x168/0x26c) (do_sys_open) from [] (SyS_openat+0x34/0x38) (SyS_openat) from [] (ret_fast_syscall+0x0/0x28) Signed-off-by: Zhaoyang Huang --- kernel/trace/trace.c | 4

Re: [PATCH] trace : use kvmalloc instead of kmalloc

On Thu, Jul 30, 2020 at 9:58 PM Steven Rostedt wrote: > > On Thu, 30 Jul 2020 19:04:12 +0800 > Zhaoyang Huang wrote: > > > High order memory stuff within trace could introduce OOM, use kvmalloc > > instead. > > > > Please find the bellowing for the ca

[PATCH] trace : use kvmalloc instead of kmalloc

/0x70) (vfs_open) from [] (path_openat+0x5fc/0x169c) (path_openat) from [] (do_filp_open+0x94/0xf8) (do_filp_open) from [] (do_sys_open+0x168/0x26c) (do_sys_open) from [] (SyS_openat+0x34/0x38) (SyS_openat) from [] (ret_fast_syscall+0x0/0x28) Signed-off-by: Zhaoyang Huang --- changes since v1: change

[PATCH] trace : use kvmalloc instead of kmalloc

/0x70) (vfs_open) from [] (path_openat+0x5fc/0x169c) (path_openat) from [] (do_filp_open+0x94/0xf8) (do_filp_open) from [] (do_sys_open+0x168/0x26c) (do_sys_open) from [] (SyS_openat+0x34/0x38) (SyS_openat) from [] (ret_fast_syscall+0x0/0x28) Signed-off-by: Zhaoyang Huang --- kernel/trace/trace.c

[PATCH] trace : use kvmalloc instead of kmalloc

[] (ret_fast_syscall+0x0/0x28) Signed-off-by: Zhaoyang Huang --- kernel/trace/trace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index ca1ee65..d4eb7ea 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -6891,7 +6891,7 @@ static

[Resend PATCH v3] arch : arm : add a criteria for pfn_valid

From: Zhaoyang Huang pfn_valid can be wrong when parsing a invalid pfn whose phys address exceeds BITS_PER_LONG as the MSB will be trimed when shifted. The issue originally arise from bellowing call stack, which corresponding to an access of the /proc/kpageflags from userspace with a invalid

[PATCH v3] arch : arm : add a criteria for pfn_valid

From: Zhaoyang Huang pfn_valid can be wrong when parsing a invalid pfn whose phys address exceeds BITS_PER_LONG as the MSB will be trimed when shifted. The issue originally arise from bellowing call stack, which corresponding to an access of the /proc/kpageflags from userspace with a invalid

[PATCH v2] arch : arm : add a criteria for pfn_valid

From: Zhaoyang Huang pfn_valid can be wrong when parsing a invalid pfn whose phys address exceeds BITS_PER_LONG as the MSB will be trimed when shifted. Signed-off-by: Zhaoyang Huang --- v2: use __pfn_to_phys/__phys_to_pfn instead of max_pfn as the criteria --- arch/arm/mm/init.c | 5 + 1

[PATCH v2] arch : arm : add a criteria for pfn_valid

From: Zhaoyang Huang pfn_valid can be wrong when parsing a invalid pfn whose phys address exceeds BITS_PER_LONG as the MSB will be trimed when shifted. Signed-off-by: Zhaoyang Huang --- arch/arm/mm/init.c | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/mm/init.c b/arch/arm

Re: [PATCH] arch : arm : add a criteria for pfn_valid

On Sun, Aug 18, 2019 at 2:32 AM Russell King - ARM Linux admin wrote: > > On Sat, Aug 17, 2019 at 11:00:13AM +0800, Zhaoyang Huang wrote: > > From: Zhaoyang Huang > > > > pfn_valid can be wrong while the MSB of physical address be trimed as pfn > > larger than

Re: [PATCH] arch : arm : add a criteria for pfn_valid

On Sat, Aug 17, 2019 at 5:00 PM Mike Rapoport wrote: > > On Sat, Aug 17, 2019 at 11:00:13AM +0800, Zhaoyang Huang wrote: > > From: Zhaoyang Huang > > > > pfn_valid can be wrong while the MSB of physical address be trimed as pfn > > larger than the max_pfn. > &g

[PATCH] arch : arm : add a criteria for pfn_valid

From: Zhaoyang Huang pfn_valid can be wrong while the MSB of physical address be trimed as pfn larger than the max_pfn. Signed-off-by: Zhaoyang Huang --- arch/arm/mm/init.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c index

Re: [[repost]RFC PATCH] mm/workingset : judge file page activity via timestamp

On Mon, May 6, 2019 at 10:57 PM Johannes Weiner wrote: > > On Sun, Apr 28, 2019 at 03:44:34PM +0800, Zhaoyang Huang wrote: > > From: Zhaoyang Huang > > > > this patch introduce timestamp into workingset's entry and judge if the > > page is > > active or in

[[repost]RFC PATCH] mm/workingset : judge file page activity via timestamp

From: Zhaoyang Huang this patch introduce timestamp into workingset's entry and judge if the page is active or inactive via active_file/refault_ratio instead of refault distance. The original thought is coming from the logs we got from trace_printk in this patch, we can find about 1/5

Re: [RFC PATCH] mm/workingset : judge file page activity via timestamp

_SHIFT - EVICTION_SECS_SHRINK_SHIFT; + max_order = fls_long(totalram_pages() - 1); if (max_order > timestamp_bits) bucket_order = max_order - timestamp_bits; On Wed, Apr 17, 2019 at 9:37 PM Matthew Wilcox wrote: > > On Wed, Apr 17, 2019 at 08:26:22PM +0800, Zhaoyang Huang wrote: >

Re: [RFC PATCH] mm/workingset : judge file page activity via timestamp

efault time. On Wed, Apr 17, 2019 at 7:46 PM Michal Hocko wrote: > > On Wed 17-04-19 19:36:21, Zhaoyang Huang wrote: > > sorry for the confusion. What I mean is the basic idea doesn't change > > as replacing the refault criteria from refault_distance to timestamp. > > B

Re: [RFC PATCH] mm/workingset : judge file page activity via timestamp

for starting a new context. On Wed, Apr 17, 2019 at 7:06 PM Michal Hocko wrote: > > On Wed 17-04-19 18:55:15, Zhaoyang Huang wrote: > > fix one mailbox and update for some information > > > > Comparing to > > http://lkml.kernel.org/r/1554348617-12897-1-git-send

Re: [RFC PATCH] mm/workingset : judge file page activity via timestamp

feedback. On Wed, Apr 17, 2019 at 3:59 PM Zhaoyang Huang wrote: > > add Johannes and answer his previous question. > > @Johannes Weiner > Yes. I do agree with you about the original thought of sacrificing > long distance access pages when huge memory demands arise. The

Re: [RFC PATCH] mm/workingset : judge file page activity via timestamp

, that is, some pages have long refault_distance while having a very short access time in between. I think the latter one should be take into consideration or as part of the finnal decision of if the page should be active/inactive. On Wed, Apr 17, 2019 at 3:48 PM Zhaoyang Huang wrote: > >

[RFC PATCH] mm/workingset : judge file page activity via timestamp

From: Zhaoyang Huang This patch introduce timestamp into workingset's entry and judge if the page is active or inactive via active_file/refault_ratio instead of refault distance. The original thought is coming from the logs we got from trace_printk in this patch, we can find about 1/5

Re: [PATCH] mm:workingset use real time to judge activity of the file page

resend it via the right mailling list and rewrite the comments by ZY. On Thu, Apr 4, 2019 at 3:15 PM Michal Hocko wrote: > > [Fixup email for Pavel and add Johannes] > > On Thu 04-04-19 11:30:17, Zhaoyang Huang wrote: > > From: Zhaoyang Huang > > > > In previ

Re: [PATCH] mm:workingset use real time to judge activity of the file page

On Fri, Apr 5, 2019 at 12:39 AM Johannes Weiner wrote: > > On Thu, Apr 04, 2019 at 11:30:17AM +0800, Zhaoyang Huang wrote: > > From: Zhaoyang Huang > > > > In previous implementation, the number of refault pages is used > > for judging the refault period of ea

[PATCH] mm:workingset use real time to judge activity of the file page

From: Zhaoyang Huang In previous implementation, the number of refault pages is used for judging the refault period of each page, which is not precised as eviction of other files will be affect a lot on current cache. We introduce the timestamp into the workingset's entry and refault ratio

[PATCH] mm:workingset use real time to judge activity of the file page

From: Zhaoyang Huang In previous implementation, the number of refault pages is used for judging the refault period of each page, which is not precised. We introduce the timestamp into the workingset's entry to measure the file page's activity. The patch is tested on an Android system, which

Re: [PATCH] driver : staging : ion: optimization for decreasing memory fragmentaion

On Wed, Mar 20, 2019 at 9:10 AM David Rientjes wrote: > > On Thu, 14 Mar 2019, Zhaoyang Huang wrote: > > > From: Zhaoyang Huang > > > > Two action for this patch: > > 1. set a batch size for system heap's shrinker, which can have it buffer > > reasonable pa

[PATCH] driver : staging : ion: optimization for decreasing memory fragmentaion

From: Zhaoyang Huang Two action for this patch: 1. set a batch size for system heap's shrinker, which can have it buffer reasonable page blocks in pool for future allocation. 2. reverse the order sequence when free page blocks, the purpose is also to have system heap keep as more big blocks

[PATCH] mm:vmalloc add vm_struct for vm_map_ram

From: Zhaoyang Huang There is no caller and pages information etc for the area which is created by vm_map_ram as well as the page count > VMAP_MAX_ALLOC. Add them on in this commit. Signed-off-by: Zhaoyang Huang --- mm/vmalloc.c | 30 -- 1 file changed,

[PATCH] mm:vmalloc add vm_struct for vm_map_ram

From: Zhaoyang Huang There is no caller and pages information etc for the area which is created by vm_map_ram as well as the page count > VMAP_MAX_ALLOC. Add them on in this commit. Signed-off-by: Zhaoyang Huang --- mm/vmalloc.c | 30 -- 1 file changed,

[PATCH] arch/arm64 : fix error in dump_backtrace

From: Zhaoyang Huang In some cases, the instruction of "bl foo1" will be the last one of the foo2[1], which will cause the lr be the first instruction of the adjacent foo3[2]. Hence, the backtrace will show the weird result as bellow[3]. The patch will fix it by miner 4 of t

[PATCH] arch/arm64 : fix error in dump_backtrace

From: Zhaoyang Huang In some cases, the instruction of "bl foo1" will be the last one of the foo2[1], which will cause the lr be the first instruction of the adjacent foo3[2]. Hence, the backtrace will show the weird result as bellow[3]. The patch will fix it by miner 4 of t

Re: [PATCH v1] mm:memcg: skip memcg of current in mem_cgroup_soft_limit_reclaim

On Fri, Aug 3, 2018 at 2:18 PM Michal Hocko wrote: > > On Fri 03-08-18 14:11:26, Zhaoyang Huang wrote: > > On Fri, Aug 3, 2018 at 1:48 PM Zhaoyang Huang > > wrote: > > > > > > for the soft_limit reclaim has more directivity than global reclaim, > > >

Re: [PATCH v1] mm:memcg: skip memcg of current in mem_cgroup_soft_limit_reclaim

On Fri, Aug 3, 2018 at 2:18 PM Michal Hocko wrote: > > On Fri 03-08-18 14:11:26, Zhaoyang Huang wrote: > > On Fri, Aug 3, 2018 at 1:48 PM Zhaoyang Huang > > wrote: > > > > > > for the soft_limit reclaim has more directivity than global reclaim, > > >

Re: [PATCH v1] mm:memcg: skip memcg of current in mem_cgroup_soft_limit_reclaim

On Fri, Aug 3, 2018 at 1:48 PM Zhaoyang Huang wrote: > > for the soft_limit reclaim has more directivity than global reclaim, we40960 > have current memcg be skipped to avoid potential page thrashing. > The patch is tested in our android system with 2GB ram. The case mainly focus o

Re: [PATCH v1] mm:memcg: skip memcg of current in mem_cgroup_soft_limit_reclaim

On Fri, Aug 3, 2018 at 1:48 PM Zhaoyang Huang wrote: > > for the soft_limit reclaim has more directivity than global reclaim, we40960 > have current memcg be skipped to avoid potential page thrashing. > The patch is tested in our android system with 2GB ram. The case mainly focus o

[PATCH v1] mm:memcg: skip memcg of current in mem_cgroup_soft_limit_reclaim

for the soft_limit reclaim has more directivity than global reclaim, we have current memcg be skipped to avoid potential page thrashing. Signed-off-by: Zhaoyang Huang --- mm/memcontrol.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/mm/memcontrol.c b/mm

[PATCH v1] mm:memcg: skip memcg of current in mem_cgroup_soft_limit_reclaim

for the soft_limit reclaim has more directivity than global reclaim, we have current memcg be skipped to avoid potential page thrashing. Signed-off-by: Zhaoyang Huang --- mm/memcontrol.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/mm/memcontrol.c b/mm

Re: [PATCH v2] mm: terminate the reclaim early when direct reclaiming

On Tue, Jul 31, 2018 at 7:19 PM Michal Hocko wrote: > > On Tue 31-07-18 19:09:28, Zhaoyang Huang wrote: > > This patch try to let the direct reclaim finish earlier than it used > > to be. The problem comes from We observing that the direct reclaim > > took a long t

Re: [PATCH v2] mm: terminate the reclaim early when direct reclaiming

On Tue, Jul 31, 2018 at 7:19 PM Michal Hocko wrote: > > On Tue 31-07-18 19:09:28, Zhaoyang Huang wrote: > > This patch try to let the direct reclaim finish earlier than it used > > to be. The problem comes from We observing that the direct reclaim > > took a long t

[PATCH v2] mm: terminate the reclaim early when direct reclaiming

barriers to judge if it has reclaimed enough memory as same criteria as it is in shrink_lruvec: 1. for each memcg softlimit reclaim. 2. before starting the global reclaim in shrink_zone. Signed-off-by: Zhaoyang Huang --- include/linux/memcontrol.h | 3 ++- mm/memcontrol.c| 3 +++ mm

[PATCH v2] mm: terminate the reclaim early when direct reclaiming

barriers to judge if it has reclaimed enough memory as same criteria as it is in shrink_lruvec: 1. for each memcg softlimit reclaim. 2. before starting the global reclaim in shrink_zone. Signed-off-by: Zhaoyang Huang --- include/linux/memcontrol.h | 3 ++- mm/memcontrol.c| 3 +++ mm

[PATCH] mm: terminate the reclaim early when direct reclaiming

barriers to judge if it has reclaimed enough memory as same criteria as it is in shrink_lruvec: 1. for each memcg softlimit reclaim. 2. before starting the global reclaim in shrink_zone. Signed-off-by: Zhaoyang Huang --- include/linux/memcontrol.h | 3 ++- mm/memcontrol.c| 3 +++ mm

[PATCH] mm: terminate the reclaim early when direct reclaiming

barriers to judge if it has reclaimed enough memory as same criteria as it is in shrink_lruvec: 1. for each memcg softlimit reclaim. 2. before starting the global reclaim in shrink_zone. Signed-off-by: Zhaoyang Huang --- include/linux/memcontrol.h | 3 ++- mm/memcontrol.c| 3 +++ mm

Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

On Wed, Apr 11, 2018 at 2:39 AM, Joel Fernandes wrote: > Hi Steve, > > On Tue, Apr 10, 2018 at 11:00 AM, Steven Rostedt wrote: >> On Tue, 10 Apr 2018 09:45:54 -0700 >> Joel Fernandes wrote: >> >>> > diff --git

Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

On Wed, Apr 11, 2018 at 2:39 AM, Joel Fernandes wrote: > Hi Steve, > > On Tue, Apr 10, 2018 at 11:00 AM, Steven Rostedt wrote: >> On Tue, 10 Apr 2018 09:45:54 -0700 >> Joel Fernandes wrote: >> >>> > diff --git a/include/linux/ring_buffer.h b/include/linux/ring_buffer.h >>> > index

Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

On Tue, Apr 10, 2018 at 5:32 PM, Zhaoyang Huang <huangzhaoy...@gmail.com> wrote: > On Tue, Apr 10, 2018 at 5:01 PM, Michal Hocko <mho...@kernel.org> wrote: >> On Tue 10-04-18 16:38:32, Zhaoyang Huang wrote: >>> On Tue, Apr 10, 2018 at 4:12 PM, Michal Hocko <mho..

Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

On Tue, Apr 10, 2018 at 5:32 PM, Zhaoyang Huang wrote: > On Tue, Apr 10, 2018 at 5:01 PM, Michal Hocko wrote: >> On Tue 10-04-18 16:38:32, Zhaoyang Huang wrote: >>> On Tue, Apr 10, 2018 at 4:12 PM, Michal Hocko wrote: >>> > On Tue 10-04-18 16:04:40, Zhaoyang Huan

Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

On Tue, Apr 10, 2018 at 5:01 PM, Michal Hocko <mho...@kernel.org> wrote: > On Tue 10-04-18 16:38:32, Zhaoyang Huang wrote: >> On Tue, Apr 10, 2018 at 4:12 PM, Michal Hocko <mho...@kernel.org> wrote: >> > On Tue 10-04-18 16:04:40, Zhaoyang Huang wrote: >> >&g

Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

On Tue, Apr 10, 2018 at 5:01 PM, Michal Hocko wrote: > On Tue 10-04-18 16:38:32, Zhaoyang Huang wrote: >> On Tue, Apr 10, 2018 at 4:12 PM, Michal Hocko wrote: >> > On Tue 10-04-18 16:04:40, Zhaoyang Huang wrote: >> >> On Tue, Apr 10, 2018 at 3:49 PM, Michal Hocko

Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

On Tue, Apr 10, 2018 at 4:12 PM, Michal Hocko <mho...@kernel.org> wrote: > On Tue 10-04-18 16:04:40, Zhaoyang Huang wrote: >> On Tue, Apr 10, 2018 at 3:49 PM, Michal Hocko <mho...@kernel.org> wrote: >> > On Tue 10-04-18 14:39:35, Zhaoyang Huang wrote: >> >&g

Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

On Tue, Apr 10, 2018 at 4:12 PM, Michal Hocko wrote: > On Tue 10-04-18 16:04:40, Zhaoyang Huang wrote: >> On Tue, Apr 10, 2018 at 3:49 PM, Michal Hocko wrote: >> > On Tue 10-04-18 14:39:35, Zhaoyang Huang wrote: >> >> On Tue, Apr 10, 2018 a

Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

On Tue, Apr 10, 2018 at 3:49 PM, Michal Hocko <mho...@kernel.org> wrote: > On Tue 10-04-18 14:39:35, Zhaoyang Huang wrote: >> On Tue, Apr 10, 2018 at 2:14 PM, Michal Hocko <mho...@kernel.org> wrote: >> > On Tue 10-04-18 11:41:44, Zhaoyang Huang wrote: >> >>

Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

On Tue, Apr 10, 2018 at 3:49 PM, Michal Hocko wrote: > On Tue 10-04-18 14:39:35, Zhaoyang Huang wrote: >> On Tue, Apr 10, 2018 at 2:14 PM, Michal Hocko wrote: >> > On Tue 10-04-18 11:41:44, Zhaoyang Huang wrote: >> >> On Tue, Apr 10, 2018 at 11:12 AM, Steven Rostedt

Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

On Tue, Apr 10, 2018 at 2:14 PM, Michal Hocko <mho...@kernel.org> wrote: > On Tue 10-04-18 11:41:44, Zhaoyang Huang wrote: >> On Tue, Apr 10, 2018 at 11:12 AM, Steven Rostedt <rost...@goodmis.org> wrote: >> > On Tue, 10 Apr 2018 10:32:36 +0800 >> > Zhaoyan

Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

On Tue, Apr 10, 2018 at 2:14 PM, Michal Hocko wrote: > On Tue 10-04-18 11:41:44, Zhaoyang Huang wrote: >> On Tue, Apr 10, 2018 at 11:12 AM, Steven Rostedt wrote: >> > On Tue, 10 Apr 2018 10:32:36 +0800 >> > Zhaoyang Huang wrote: >> > >> >> For

Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

On Tue, Apr 10, 2018 at 11:12 AM, Steven Rostedt <rost...@goodmis.org> wrote: > On Tue, 10 Apr 2018 10:32:36 +0800 > Zhaoyang Huang <huangzhaoy...@gmail.com> wrote: > >> For bellowing scenario, process A have no intension to exhaust the >> memory, but will be li

Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

On Tue, Apr 10, 2018 at 11:12 AM, Steven Rostedt wrote: > On Tue, 10 Apr 2018 10:32:36 +0800 > Zhaoyang Huang wrote: > >> For bellowing scenario, process A have no intension to exhaust the >> memory, but will be likely to be selected by OOM for we set >> OOM_CORE

Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

On Tue, Apr 10, 2018 at 8:32 AM, Zhaoyang Huang <huangzhaoy...@gmail.com> wrote: > On Mon, Apr 9, 2018 at 9:49 PM, Steven Rostedt <rost...@goodmis.org> wrote: >> On Mon, 9 Apr 2018 08:56:01 +0800 >> Zhaoyang Huang <huangzhaoy...@gmail.com> wrote: >> >>

Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

On Tue, Apr 10, 2018 at 8:32 AM, Zhaoyang Huang wrote: > On Mon, Apr 9, 2018 at 9:49 PM, Steven Rostedt wrote: >> On Mon, 9 Apr 2018 08:56:01 +0800 >> Zhaoyang Huang wrote: >> >>> >> >>> >> if (oom_task_origin

Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

On Mon, Apr 9, 2018 at 9:49 PM, Steven Rostedt <rost...@goodmis.org> wrote: > On Mon, 9 Apr 2018 08:56:01 +0800 > Zhaoyang Huang <huangzhaoy...@gmail.com> wrote: > >> >> >> >> if (oom_task_origin(task)) { >> >>

Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

On Mon, Apr 9, 2018 at 9:49 PM, Steven Rostedt wrote: > On Mon, 9 Apr 2018 08:56:01 +0800 > Zhaoyang Huang wrote: > >> >> >> >> if (oom_task_origin(task)) { >> >> points = ULONG_MAX; >> >>

Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

On Sun, Apr 8, 2018 at 8:47 PM, Steven Rostedt <rost...@goodmis.org> wrote: > [ Removing kernel-patch-test, because of annoying "moderator" messages ] > > On Sun, 8 Apr 2018 13:54:59 +0800 > Zhaoyang Huang <huangzhaoy...@gmail.com> wrote: > >> On Sun, Ap

Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

On Sun, Apr 8, 2018 at 8:47 PM, Steven Rostedt wrote: > [ Removing kernel-patch-test, because of annoying "moderator" messages ] > > On Sun, 8 Apr 2018 13:54:59 +0800 > Zhaoyang Huang wrote: > >> On Sun, Apr 8, 2018 at 11:48 AM, Steven Rostedt wrote: >>

Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

On Sun, Apr 8, 2018 at 11:48 AM, Steven Rostedt <rost...@goodmis.org> wrote: > On Sun, 8 Apr 2018 10:16:23 +0800 > Zhaoyang Huang <huangzhaoy...@gmail.com> wrote: > >> Don't choose the process with adj == OOM_SCORE_ADJ_MIN which >> over-allocating pages for ri

Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

On Sun, Apr 8, 2018 at 11:48 AM, Steven Rostedt wrote: > On Sun, 8 Apr 2018 10:16:23 +0800 > Zhaoyang Huang wrote: > >> Don't choose the process with adj == OOM_SCORE_ADJ_MIN which >> over-allocating pages for ring buffers. > > Why? > > -- Steve because

[PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

Don't choose the process with adj == OOM_SCORE_ADJ_MIN which over-allocating pages for ring buffers. Signed-off-by: Zhaoyang Huang <zhaoyang.hu...@spreadtrum.com> --- kernel/trace/ring_buffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/ring_buff

[PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

Don't choose the process with adj == OOM_SCORE_ADJ_MIN which over-allocating pages for ring buffers. Signed-off-by: Zhaoyang Huang --- kernel/trace/ring_buffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index

Re: [PATCH] ring-buffer: Add set/clear_current_oom_origin() during allocations

On Fri, Apr 6, 2018 at 7:36 AM, Joel Fernandes wrote: > Hi Steve, > > On Thu, Apr 5, 2018 at 12:57 PM, Joel Fernandes wrote: >> On Thu, Apr 5, 2018 at 6:43 AM, Steven Rostedt wrote: >>> On Wed, 4 Apr 2018 16:59:18 -0700 >>> Joel

Re: [PATCH] ring-buffer: Add set/clear_current_oom_origin() during allocations

On Fri, Apr 6, 2018 at 7:36 AM, Joel Fernandes wrote: > Hi Steve, > > On Thu, Apr 5, 2018 at 12:57 PM, Joel Fernandes wrote: >> On Thu, Apr 5, 2018 at 6:43 AM, Steven Rostedt wrote: >>> On Wed, 4 Apr 2018 16:59:18 -0700 >>> Joel Fernandes wrote: >>> Happy to try anything else, BTW when

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Wed, Apr 4, 2018 at 2:23 PM, Michal Hocko <mho...@kernel.org> wrote: > On Wed 04-04-18 10:58:39, Zhaoyang Huang wrote: >> On Tue, Apr 3, 2018 at 9:56 PM, Michal Hocko <mho...@kernel.org> wrote: >> > On Tue 03-04-18 09:32:45, Steven Rostedt wrote: >>

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Wed, Apr 4, 2018 at 2:23 PM, Michal Hocko wrote: > On Wed 04-04-18 10:58:39, Zhaoyang Huang wrote: >> On Tue, Apr 3, 2018 at 9:56 PM, Michal Hocko wrote: >> > On Tue 03-04-18 09:32:45, Steven Rostedt wrote: >> >> On Tue, 3 Apr 2018 14:35:14 +

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Tue, Apr 3, 2018 at 9:56 PM, Michal Hocko wrote: > On Tue 03-04-18 09:32:45, Steven Rostedt wrote: >> On Tue, 3 Apr 2018 14:35:14 +0200 >> Michal Hocko wrote: > [...] >> > Being clever is OK if it doesn't add a tricky code. And relying on >> >

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Tue, Apr 3, 2018 at 9:56 PM, Michal Hocko wrote: > On Tue 03-04-18 09:32:45, Steven Rostedt wrote: >> On Tue, 3 Apr 2018 14:35:14 +0200 >> Michal Hocko wrote: > [...] >> > Being clever is OK if it doesn't add a tricky code. And relying on >> > si_mem_available is definitely tricky and

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Sat, Mar 31, 2018 at 5:42 AM, Steven Rostedt wrote: > On Fri, 30 Mar 2018 17:30:31 -0400 > Steven Rostedt wrote: > >> I'll take a look at si_mem_available() that Joel suggested and see if >> we can make that work. > > Wow, this appears to work great!

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Sat, Mar 31, 2018 at 5:42 AM, Steven Rostedt wrote: > On Fri, 30 Mar 2018 17:30:31 -0400 > Steven Rostedt wrote: > >> I'll take a look at si_mem_available() that Joel suggested and see if >> we can make that work. > > Wow, this appears to work great! Joel and Zhaoyang, can you test this? > >

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Fri, Mar 30, 2018 at 12:05 AM, Steven Rostedt <rost...@goodmis.org> wrote: > On Thu, 29 Mar 2018 18:41:44 +0800 > Zhaoyang Huang <huangzhaoy...@gmail.com> wrote: > >> It is reported that some user app would like to echo a huge >> number to "/sys/kernel/de

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Fri, Mar 30, 2018 at 12:05 AM, Steven Rostedt wrote: > On Thu, 29 Mar 2018 18:41:44 +0800 > Zhaoyang Huang wrote: > >> It is reported that some user app would like to echo a huge >> number to "/sys/kernel/debug/tracing/buffer_size_kb" regardless >> of t

[PATCH v1] kernel/trace:check the val against the available mem

t to avoid the consequence allocation. Signed-off-by: Zhaoyang Huang <zhaoyang.hu...@spreadtrum.com> --- kernel/trace/trace.c | 39 ++- 1 file changed, 38 insertions(+), 1 deletion(-) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 2d0ffcc

[PATCH v1] kernel/trace:check the val against the available mem

t to avoid the consequence allocation. Signed-off-by: Zhaoyang Huang --- kernel/trace/trace.c | 39 ++- 1 file changed, 38 insertions(+), 1 deletion(-) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 2d0ffcc..a4a4237 100644 --- a/kernel/trace/tra

Re: [PATCH v1] mm: help the ALLOC_HARDER allocation pass the watermarki when CMA on

On Fri, Mar 23, 2018 at 4:38 PM, Michal Hocko <mho...@kernel.org> wrote: > On Fri 23-03-18 15:57:32, Zhaoyang Huang wrote: >> For the type of 'ALLOC_HARDER' page allocation, there is an express >> highway for the whole process which lead the allocation reach __rmqueue_xxx >

Re: [PATCH v1] mm: help the ALLOC_HARDER allocation pass the watermarki when CMA on

On Fri, Mar 23, 2018 at 4:38 PM, Michal Hocko wrote: > On Fri 23-03-18 15:57:32, Zhaoyang Huang wrote: >> For the type of 'ALLOC_HARDER' page allocation, there is an express >> highway for the whole process which lead the allocation reach __rmqueue_xxx >> easier than other t

[PATCH v1] mm: help the ALLOC_HARDER allocation pass the watermarki when CMA on

may cause the watermark check fail, but there are possible enough HighAtomic or Unmovable and Reclaimable pages in the zone. So add 'alloc_harder' here to count CMA pages in to clean the obstacles on the way to the final. Signed-off-by: Zhaoyang Huang <zhaoyang.hu...@spreadtrum.com> -

[PATCH v1] mm: help the ALLOC_HARDER allocation pass the watermarki when CMA on

may cause the watermark check fail, but there are possible enough HighAtomic or Unmovable and Reclaimable pages in the zone. So add 'alloc_harder' here to count CMA pages in to clean the obstacles on the way to the final. Signed-off-by: Zhaoyang Huang --- mm/page_alloc.c | 7 +-- 1 file changed

[PATCH v1] mm/vmalloc: add a node corresponding to cached_hole_size

st in front of the cached_hole_size, which can help to avoid walking the rb tree and the list and make the T = 0; Signed-off-by: Zhaoyang Huang <zhaoyang.hu...@spreadtrum.com> --- mm/vmalloc.c | 23 +-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/mm/vmalloc

[PATCH v1] mm/vmalloc: add a node corresponding to cached_hole_size

st in front of the cached_hole_size, which can help to avoid walking the rb tree and the list and make the T = 0; Signed-off-by: Zhaoyang Huang --- mm/vmalloc.c | 23 +-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 8698c1c..4e

  1   2   >