Re: [RFC v2 5/6] arm: cpuidle: let genpd handle the cluster power transition with 'power-states'

On 6 October 2015 at 22:27, Marc Titinger wrote: > From: Marc Titinger > > Cpuidle now handles c-states and power-states differently. c-states do not > decrement > the reference count for the CPUs in the cluster, while power-states i.e. > cluster

Re: [PATCH v10 3/6] PM / Domains: make governor select deepest state

On 20 October 2015 at 21:26, wrote: > From: Axel Haslam > > Now that the structures of genpd can support multiple state definitions, > add the logic in the governor to select the deepest possible state when > powering down. > > For this,

Re: [RFC v3 2/7] PM / Domains: support idle-states as genpd multiple-state.

On 28 October 2015 at 01:40, Marc Titinger wrote: > From: Marc Titinger > > This patch allows cluster-level idle-states to being soaked in as generic > domain power states, in order for the domain governor to chose the most > efficient power state

[PATCH] modify pl011 driver to let it work as wakeup source

the commit use the latest dev_pm_set_wake_irq API instead of the enable_irq_wake and IRQF_NO_SUSPEND to configure the ttyAMA device to work as the wakeup source Signed-off-by: Zhaoyang Huang <zhaoyang.hu...@linaro.org> --- drivers/tty/serial/amba-pl011.c

[RFC PATCH v2 2/2] power/idle: enhance the precision of sleep_length

From: Zhaoyang Huang <zhaoyang.hu...@spreadtrum.com> There should be a gap between tick_nohz_idle_enter and tick_nohz_get_sleep_length when idle, which will cause the sleep_length is not very precised. Change it in this patch. Signed-off-by: Zhaoyang Huang <zhaoyang.hu...@sprea

[RFC PATCH v2 1/2] power/cpuidle: enhance the precision of state select

From: Zhaoyang Huang <zhaoyang.hu...@spreadtrum.com> In previous version, cpu_pm_enter is invoked after the governor select the state, which cause the executing time of cpu_pm_enter is included in the idle time. Moving it before the state selection. Signed-off-by: Zhaoyang Huang <zh

[RFC PATCH] power/cpuidle: enhance the precision of state select

In previous version, cpu_pm_enter is invoked after the governor select the state, which cause the executing time of cpu_pm_enter is included in the idle time. Moving it before the state selection. Signed-off-by: Zhaoyang Huang <zhaoyang.hu...@spreadtrum.com> --- kernel/sched/idle.c

Re: [RESEND PATCH v2 2/2] power/idle: enhance the precision of sleep_length

On 20 June 2016 at 09:14, Zhaoyang Huang <zhaoyang.hu...@linaro.org> wrote: > On 17 June 2016 at 19:50, Thomas Gleixner <t...@linutronix.de> wrote: >> On Fri, 17 Jun 2016, Zhaoyang Huang wrote: >>> On 17 June 2016 at 17:27, Thomas Gleixner <t...@linutronix.de&

[RESEND PATCH v2 1/2] power/cpuidle: enhance the precision of state select

In previous version, cpu_pm_enter is invoked after the governor select the state, which cause the executing time of cpu_pm_enter is included in the idle time. Moving it before the state selection. Signed-off-by: Zhaoyang Huang <zhaoyang.hu...@spreadtrum.com> --- kernel/sched/idle.c

[RESEND PATCH v2 2/2] power/idle: enhance the precision of sleep_length

There should be a gap between tick_nohz_idle_enter and tick_nohz_get_sleep_length when idle, which will cause the sleep_length is not very precised. Change it in this patch. Signed-off-by: Zhaoyang Huang <zhaoyang.hu...@spreadtrum.com> --- kernel/time/tick-sched.c |5 + 1 file chan

Re: [RESEND PATCH v2 2/2] power/idle: enhance the precision of sleep_length

On 23 June 2016 at 15:01, Thomas Gleixner <t...@linutronix.de> wrote: > On Wed, 22 Jun 2016, Zhaoyang Huang wrote: >> On 20 June 2016 at 09:14, Zhaoyang Huang <zhaoyang.hu...@linaro.org> wrote: >> > On 17 June 2016 at 19:50, Thomas Gleixner <t...@linutronix.de&

Re: [RESEND PATCH v2 2/2] power/idle: enhance the precision of sleep_length

On 23 June 2016 at 16:18, Thomas Gleixner <t...@linutronix.de> wrote: > On Thu, 23 Jun 2016, Zhaoyang Huang wrote: >> On 23 June 2016 at 15:01, Thomas Gleixner <t...@linutronix.de> wrote: >> Thomas, I agree with you, I have discussed the modification with the >> c

Re: [RESEND PATCH v2 2/2] power/idle: enhance the precision of sleep_length

On 23 June 2016 at 16:35, Thomas Gleixner <t...@linutronix.de> wrote: > On Thu, 23 Jun 2016, Zhaoyang Huang wrote: >> On 23 June 2016 at 16:18, Thomas Gleixner <t...@linutronix.de> wrote: >> > On Thu, 23 Jun 2016, Zhaoyang Huang wrote: >> >> On

Re: [RESEND PATCH v2 1/2] power/cpuidle: enhance the precision of state select

On 25 June 2016 at 09:09, Rafael J. Wysocki <raf...@kernel.org> wrote: > On Fri, Jun 17, 2016 at 11:13 AM, Zhaoyang Huang > <zhaoyang.hu...@linaro.org> wrote: >> In previous version, cpu_pm_enter is invoked > > By whom? Not by the core surely? > >> after the

Re: [RESEND PATCH v2 2/2] power/idle: enhance the precision of sleep_length

On 17 June 2016 at 17:27, Thomas Gleixner <t...@linutronix.de> wrote: > On Fri, 17 Jun 2016, Zhaoyang Huang wrote: >> There should be a gap between tick_nohz_idle_enter and >> tick_nohz_get_sleep_length when idle, which will cause the >> sleep_length is not very precis

[RFC PATCH v3] POWER/runtime: refining the rpm_suspend function

pend_wait- | | | | | V | _rpm_suspend_call>_rpm_suspend_fail | | | | V V _rpm_suspend_success--->END Signed-off-by: Zhaoyang Huang <zhaoyang.hu...@spreadtrum.com> --- drivers

Re: [RFC PATCH v2] Add IPI entry for CPU UP

0:17:42AM +0800, Zhaoyang Huang wrote: >> > On 12 January 2016 at 10:05, Zhaoyang Huang <zhaoyang.hu...@linaro.org> >> > wrote: >> > > In some ARM SOCs, IPI interrupt is used for hotplug in one cpu, that is, >> > > sending a IPI to the core in WFI and p

Re: [RFC PATCH v2] Add IPI entry for CPU UP

On 21 January 2016 at 18:51, Mark Rutland <mark.rutl...@arm.com> wrote: > On Thu, Jan 21, 2016 at 04:48:57PM +0800, Zhaoyang Huang wrote: >> Hi Mark, > > Hi, > >> Do you have any suggestion on how to sync the GIC operation from >> kernel and psci parallelly? Th

Re: [RFC PATCH v3] POWER/runtime: refining the rpm_suspend function

On 22 January 2016 at 03:32, Pavel Machek wrote: > >> - goto repeat; >> + >> + /*check expires firstly for auto suspend mode, >> + *if not, just go ahead to the async >> + */ > > English, coding style. >

[RFC PATCH v3 1/2] power/cpuidle: enhance the precision of state select

R 3.now 4.select idle statenext_event (sleep_length) Signed-off-by: Zhaoyang Huang <zhaoyang.hu...@spreadtrum.com> --- kernel/sched/idle.c | 18 -- 1 file changed, 12 insertions(+), 6 deletio

[RFC PATCH v3 2/2] power/idle: enhance the precision of sleep_length

| 1.IDLE_START 2.CPU_PM_ENTER 3.now 4.select idle statenext_event (sleep_length) Signed-off-by: Zhaoyang Huang <zhaoyang.hu..

Re: [RESEND PATCH v2 2/2] power/idle: enhance the precision of sleep_length

On 17 June 2016 at 19:50, Thomas Gleixner <t...@linutronix.de> wrote: > On Fri, 17 Jun 2016, Zhaoyang Huang wrote: >> On 17 June 2016 at 17:27, Thomas Gleixner <t...@linutronix.de> wrote: >> > On Fri, 17 Jun 2016, Zhaoyang Huang wrote: >> >> There sh

[PATCH v2] mm/vmalloc: terminate searching since one node found

From: Zhaoyang Huang <zhaoyang.hu...@spreadtrum.com:wq> It is no need to find the very beginning of the area within alloc_vmap_area, which can be done by judging each node during the process For current approach, the worst case is that the starting node which be found for sea

[PATCH v3] mm/vmalloc: terminate searching since one node found

/ ... (1) / first(current approach) vmap_area_list->...->first->...->tmp->tmp_next (2) Signed-off-by: Zhaoyang Huang <zhaoyang.hu...@spreadtrum.com> --- mm/vmalloc.c | 9 + 1 file changed, 9 insertions(+) diff --gi

Re: [PATCH v2] mm/vmalloc: terminate searching since one node found

On Mon, Jul 17, 2017 at 4:29 PM, Michal Hocko <mho...@kernel.org> wrote: > On Mon 17-07-17 15:27:31, Zhaoyang Huang wrote: >> From: Zhaoyang Huang <zhaoyang.hu...@spreadtrum.com:wq> >> >> It is no need to find the very beginning of the area within >> alloc_

[PATCH v4] mm/vmalloc: terminate searching since one node found

t just take effect when free_vmap_cache miss and will reestablish it laterly. Signed-off-by: Zhaoyang Huang <zhaoyang.hu...@spreadtrum.com> --- mm/vmalloc.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 8698c1c..f58f445 100644 --- a/mm/vmal

[PATCH] mm/vmalloc: terminate searching since one node found

It is no need to find the very beginning of the area within alloc_vmap_area, which can be done by judging each node during the process Signed-off-by: Zhaoyang Huang <zhaoyang.hu...@spreadtrum.com> Signed-off-by: Zhaoyang Huang <huangzhaoy...@gmail.com> --- mm/vmalloc.c | 7 +++

[PATCH] mm/vmalloc: terminate searching since one node found

From: Zhaoyang Huang <zhaoyang.hu...@spreadtrum.com:wq> It is no need to find the very beginning of the area within alloc_vmap_area, which can be done by judging each node during the process Signed-off-by: Zhaoyang Huang <zhaoyang.hu...@spreadtrum.com> --- mm/vmalloc.c | 7 +++

[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

Re: [PATCH] mm/vmalloc: add vm_struct for vm_map_ram area

On Thu, Jul 20, 2017 at 4:50 AM, Andrew Morton <a...@linux-foundation.org> wrote: > On Wed, 19 Jul 2017 18:44:03 +0800 Zhaoyang Huang <huangzhaoy...@gmail.com> > wrote: > >> /proc/vmallocinfo will not show the area allocated by vm_map_ram, which >> will make co

Re: [PATCH] mm/vmalloc: add vm_struct for vm_map_ram area

update the comment bellow as ...'s/by one driver's allocating/because one driver has allocated/'..., sorry for the confusion On Thu, Jul 20, 2017 at 9:15 AM, Zhaoyang Huang <huangzhaoy...@gmail.com> wrote: > On Thu, Jul 20, 2017 at 4:50 AM, Andrew Morton > <a...@linux-founda

[PATCH] mm/vmalloc: add vm_struct for vm_map_ram area

/proc/vmallocinfo will not show the area allocated by vm_map_ram, which will make confusion when debug. Add vm_struct for them and show them in proc. Signed-off-by: Zhaoyang Huang <zhaoyang.hu...@spreadtrum.com> --- mm/vmalloc.c | 27 ++- 1 file changed, 26 inse

[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 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 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, > > >

[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 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

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: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 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 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 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 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 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 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 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 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] 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 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

[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

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!

[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

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 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 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: >>

[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> -

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 >

[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 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

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] 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] 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

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 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] 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] 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 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 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 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 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 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 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 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 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

[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 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

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] 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? > >

[PATCH] mm/vmalloc: terminate searching since one node found

From: Zhaoyang Huang It is no need to find the very beginning of the area within alloc_vmap_area, which can be done by judging each node during the process Signed-off-by: Zhaoyang Huang --- mm/vmalloc.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/mm/vmalloc.c b/mm/vmalloc.c

[PATCH] mm/vmalloc: terminate searching since one node found

It is no need to find the very beginning of the area within alloc_vmap_area, which can be done by judging each node during the process Signed-off-by: Zhaoyang Huang Signed-off-by: Zhaoyang Huang --- mm/vmalloc.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/mm/vmalloc.c b/mm

[PATCH v2] mm/vmalloc: terminate searching since one node found

From: Zhaoyang Huang It is no need to find the very beginning of the area within alloc_vmap_area, which can be done by judging each node during the process For current approach, the worst case is that the starting node which be found for searching the 'vmap_area_list' is close to the 'vstart

[PATCH v3] mm/vmalloc: terminate searching since one node found

/ ... (1) / first(current approach) vmap_area_list->...->first->...->tmp->tmp_next (2) Signed-off-by: Zhaoyang Huang --- mm/vmalloc.c | 9 + 1 file changed, 9 insertions(+) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 34a1c3e.

Re: [PATCH v2] mm/vmalloc: terminate searching since one node found

On Mon, Jul 17, 2017 at 4:29 PM, Michal Hocko wrote: > On Mon 17-07-17 15:27:31, Zhaoyang Huang wrote: >> From: Zhaoyang Huang >> >> It is no need to find the very beginning of the area within >> alloc_vmap_area, which can be done by judging each node during th

[PATCH] mm/vmalloc: add vm_struct for vm_map_ram area

/proc/vmallocinfo will not show the area allocated by vm_map_ram, which will make confusion when debug. Add vm_struct for them and show them in proc. Signed-off-by: Zhaoyang Huang --- mm/vmalloc.c | 27 ++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/mm

Re: [PATCH] mm/vmalloc: add vm_struct for vm_map_ram area

On Thu, Jul 20, 2017 at 4:50 AM, Andrew Morton wrote: > On Wed, 19 Jul 2017 18:44:03 +0800 Zhaoyang Huang > wrote: > >> /proc/vmallocinfo will not show the area allocated by vm_map_ram, which >> will make confusion when debug. Add vm_struct for them and show them in &

Re: [PATCH] mm/vmalloc: add vm_struct for vm_map_ram area

update the comment bellow as ...'s/by one driver's allocating/because one driver has allocated/'..., sorry for the confusion On Thu, Jul 20, 2017 at 9:15 AM, Zhaoyang Huang wrote: > On Thu, Jul 20, 2017 at 4:50 AM, Andrew Morton > wrote: >> On Wed, 19 Jul 2017 18:44:03 +0800 Zh

[PATCH v4] mm/vmalloc: terminate searching since one node found

t just take effect when free_vmap_cache miss and will reestablish it laterly. Signed-off-by: Zhaoyang Huang --- mm/vmalloc.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 8698c1c..f58f445 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -471,9

[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

[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] 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

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

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: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: &

[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 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-&

[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

[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/

[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

  1   2   >