Re: [RFC PATCH 10/10] psi: aggregate ongoing stall events when somebody reads pressure

On Fri, Jul 13, 2018 at 3:49 PM, Johannes Weiner wrote: > On Fri, Jul 13, 2018 at 03:13:07PM -0700, Suren Baghdasaryan wrote: >> On Thu, Jul 12, 2018 at 10:29 AM, Johannes Weiner wrote: >> > might want to know about and react to stall states before they have >> > even

Re: [RFC PATCH 10/10] psi: aggregate ongoing stall events when somebody reads pressure

ressure > metrics are read, the current per-cpu states, if any, are taken into > account as well. > > Any ongoing states are concluded, their time snapshotted, and then > restarted. This requires holding the rq lock to avoid corruption. It > could use some form of rq lock rateli

Re: [PATCH 0/7] psi: pressure stall information for CPU, memory, and IO

Hi Johannes, I tried your previous memdelay patches before this new set was posted and results were promising for predicting when Android system is close to OOM. I'm definitely going to try this one after I backport it to 4.9. On Mon, May 7, 2018 at 2:01 PM, Johannes Weiner wrote: > Hi, > > I pre

Re: [PATCH] dm bufio: fix shrinker scans when (nr_to_scan < retain_target)

Dear kernel maintainers. I know it was close to holiday season when I send this patch last month, so delay was expected. Could you please take a look at it and provide your feedback? Thanks! On Wed, Dec 6, 2017 at 9:27 AM, Suren Baghdasaryan wrote: > When system is under memory pressure it

Re: [PATCH v2] mm: terminate shrink_slab loop if signal is pending

On Sun, Dec 10, 2017 at 2:13 AM, Michal Hocko wrote: > On Fri 08-12-17 10:06:26, Suren Baghdasaryan wrote: >> On Fri, Dec 8, 2017 at 6:03 AM, Tetsuo Handa >> wrote: >> > Michal Hocko wrote: >> >> On Fri 08-12-17 20:36:16, Tetsuo Handa wrote: >> &g

Re: [PATCH v2] mm: terminate shrink_slab loop if signal is pending

On Sat, Dec 9, 2017 at 12:08 AM, Tetsuo Handa wrote: > Suren Baghdasaryan wrote: >> On Fri, Dec 8, 2017 at 6:03 AM, Tetsuo Handa >> wrote: >> >> > >> This change checks for pending >> >> > >> fatal signals inside shrink_slab loop and

Re: [PATCH v2] mm: terminate shrink_slab loop if signal is pending

On Fri, Dec 8, 2017 at 1:02 PM, David Rientjes wrote: > On Thu, 7 Dec 2017, Suren Baghdasaryan wrote: > >> Slab shrinkers can be quite time consuming and when signal >> is pending they can delay handling of the signal. If fatal >> signal is pending there is no point i

Re: [PATCH v2] mm: terminate shrink_slab loop if signal is pending

On Fri, Dec 8, 2017 at 6:03 AM, Tetsuo Handa wrote: > Michal Hocko wrote: >> On Fri 08-12-17 20:36:16, Tetsuo Handa wrote: >> > On 2017/12/08 17:22, Michal Hocko wrote: >> > > On Thu 07-12-17 17:23:05, Suren Baghdasaryan wrote: >> > >> Slab shrinker

Re: [PATCH] mm: terminate shrink_slab loop if signal is pending

> According to my traces this 43ms could drop to the average of 11ms and > worst case 25ms if throttle_direct_reclaim would return true when > fatal signal is pending but I would like to hear your opinion about > throttle_direct_reclaim logic. Digging some more into this I realize my last statemen

[PATCH v2] mm: terminate shrink_slab loop if signal is pending

detected terminates this loop early. Signed-off-by: Suren Baghdasaryan --- V2: Sergey Senozhatsky: - Fix missing parentheses --- mm/vmscan.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/mm/vmscan.c b/mm/vmscan.c index c02c850ea349..28e4bdc72c16 100644 --- a/mm/vmscan.c +++ b/mm

Re: [PATCH] mm: terminate shrink_slab loop if signal is pending

On Thu, Dec 7, 2017 at 12:34 AM, Michal Hocko wrote: > On Wed 06-12-17 11:20:26, Suren Baghdasaryan wrote: >> Slab shrinkers can be quite time consuming and when signal >> is pending they can delay handling of the signal. If fatal >> signal is pending there is no point in s

Re: [PATCH] mm: terminate shrink_slab loop if signal is pending

17 at 1:58 AM, Michal Hocko wrote: > On Thu 07-12-17 18:52:23, Sergey Senozhatsky wrote: >> On (12/06/17 11:20), Suren Baghdasaryan wrote: >> > Slab shrinkers can be quite time consuming and when signal >> > is pending they can delay handling of the signal. If fatal >&g

Re: [PATCH] mm: terminate shrink_slab loop if signal is pending

> > Some quantification of "quite time consuming" and "delay" would be > interesting, please. > Unfortunately that depends on the implementation of the shrinkers registered in the system including the ones from drivers. I've captured traces showing delays of up to 100ms where the process with pend

[PATCH] mm: terminate shrink_slab loop if signal is pending

detected terminates this loop early. Signed-off-by: Suren Baghdasaryan --- mm/vmscan.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/mm/vmscan.c b/mm/vmscan.c index c02c850ea349..69296528ff33 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -486,6 +486,13 @@ static unsigned long

[PATCH] dm bufio: fix shrinker scans when (nr_to_scan < retain_target)

ker scans Signed-off-by: Suren Baghdasaryan --- drivers/md/dm-bufio.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/md/dm-bufio.c b/drivers/md/dm-bufio.c index b8ac5917..c546b567f3b5 100644 --- a/drivers/md/dm-bufio.c +++ b/drivers/md/dm-bufio.c @@ -1611,

<    1   2   3   4