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

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

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

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 shrinking that process

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

I'm, terribly sorry. My original code was checking for additional condition which I realized is not useful here because it would mean the signal was already processed. Should have missed the error while removing it. Will address Michal's comments and fix the problem. On Thu, Dec 7, 2017 at 1:58

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

I'm, terribly sorry. My original code was checking for additional condition which I realized is not useful here because it would mean the signal was already processed. Should have missed the error while removing it. Will address Michal's comments and fix the problem. On Thu, Dec 7, 2017 at 1:58

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

On Thu 07-12-17 07:46:07, Suren Baghdasaryan wrote: > I'm, terribly sorry. My original code was checking for additional > condition which I realized is not useful here because it would mean > the signal was already processed. Should have missed the error while > removing it. Will address Michal's

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

On Thu 07-12-17 07:46:07, Suren Baghdasaryan wrote: > I'm, terribly sorry. My original code was checking for additional > condition which I realized is not useful here because it would mean > the signal was already processed. Should have missed the error while > removing it. Will address Michal's

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

On 2017/12/07 17:34, 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 shrinking that process >> since it

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

On 2017/12/07 17:34, 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 shrinking that process >> since it

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

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 > > signal is pending there is no point in shrinking that process > >

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

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 > > signal is pending there is no point in shrinking that process > >

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

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 > signal is pending there is no point in shrinking that process > since it will be killed anyway. This change checks for pending

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

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 > signal is pending there is no point in shrinking that process > since it will be killed anyway. This change checks for pending

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

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 shrinking that process > since it will be killed anyway. This change checks for

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

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 shrinking that process > since it will be killed anyway. This change checks for

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

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

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

On Wed, 6 Dec 2017 11:20:26 -0800 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 shrinking that process > since it will be killed

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

On Wed, 6 Dec 2017 11:20:26 -0800 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 shrinking that process > since it will be killed anyway. This change

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

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 shrinking that process since it will be killed anyway. This change checks for pending fatal signals inside shrink_slab loop and if one is

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

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 shrinking that process since it will be killed anyway. This change checks for pending fatal signals inside shrink_slab loop and if one is