On Fri, Jul 06, 2018 at 07:39:42AM +0200, Michal Hocko wrote:
> On Tue 03-07-18 09:01:01, Paul E. McKenney wrote:
> > On Tue, Jul 03, 2018 at 09:24:13AM +0200, Michal Hocko wrote:
> > > On Mon 02-07-18 14:37:14, Paul E. McKenney wrote:
> > > [...]
> > > > commit d2b8d16b97ac2859919713b2d98b8a3ad229
On Tue 03-07-18 09:01:01, Paul E. McKenney wrote:
> On Tue, Jul 03, 2018 at 09:24:13AM +0200, Michal Hocko wrote:
> > On Mon 02-07-18 14:37:14, Paul E. McKenney wrote:
> > [...]
> > > commit d2b8d16b97ac2859919713b2d98b8a3ad22943a2
> > > Author: Paul E. McKenney
> > > Date: Mon Jul 2 14:30:37 20
On Tue, Jul 03, 2018 at 09:24:13AM +0200, Michal Hocko wrote:
> On Mon 02-07-18 14:37:14, Paul E. McKenney wrote:
> [...]
> > commit d2b8d16b97ac2859919713b2d98b8a3ad22943a2
> > Author: Paul E. McKenney
> > Date: Mon Jul 2 14:30:37 2018 -0700
> >
> > rcu: Remove OOM code
> >
> > Th
On Mon 02-07-18 14:37:14, Paul E. McKenney wrote:
[...]
> commit d2b8d16b97ac2859919713b2d98b8a3ad22943a2
> Author: Paul E. McKenney
> Date: Mon Jul 2 14:30:37 2018 -0700
>
> rcu: Remove OOM code
>
> There is reason to believe that RCU's OOM code isn't really helping
> that muc
On Sat, Jun 30, 2018 at 10:05:22AM -0700, Paul E. McKenney wrote:
> On Fri, Jun 29, 2018 at 03:26:38PM +0200, Michal Hocko wrote:
> > On Fri 29-06-18 05:52:18, Paul E. McKenney wrote:
> > > On Fri, Jun 29, 2018 at 11:04:19AM +0200, Michal Hocko wrote:
> > > > On Thu 28-06-18 14:31:05, Paul E. McKen
On Sat 30-06-18 10:05:22, Paul E. McKenney wrote:
> On Fri, Jun 29, 2018 at 03:26:38PM +0200, Michal Hocko wrote:
> > On Fri 29-06-18 05:52:18, Paul E. McKenney wrote:
> > > On Fri, Jun 29, 2018 at 11:04:19AM +0200, Michal Hocko wrote:
> > > > On Thu 28-06-18 14:31:05, Paul E. McKenney wrote:
> > >
On Fri, Jun 29, 2018 at 11:35:48PM +0900, Tetsuo Handa wrote:
> On 2018/06/29 21:52, Paul E. McKenney wrote:
> > The effect of RCU's current OOM code is to speed up callback invocation
> > by at most a few seconds (assuming no stalled CPUs, in which case
> > it is not possible to speed up callback
On Fri, Jun 29, 2018 at 03:26:38PM +0200, Michal Hocko wrote:
> On Fri 29-06-18 05:52:18, Paul E. McKenney wrote:
> > On Fri, Jun 29, 2018 at 11:04:19AM +0200, Michal Hocko wrote:
> > > On Thu 28-06-18 14:31:05, Paul E. McKenney wrote:
> > > > On Thu, Jun 28, 2018 at 01:39:42PM +0200, Michal Hocko
On 2018/06/29 21:52, Paul E. McKenney wrote:
> The effect of RCU's current OOM code is to speed up callback invocation
> by at most a few seconds (assuming no stalled CPUs, in which case
> it is not possible to speed up callback invocation).
>
> Given that, I should just remove RCU's OOM code enti
On Fri 29-06-18 05:52:18, Paul E. McKenney wrote:
> On Fri, Jun 29, 2018 at 11:04:19AM +0200, Michal Hocko wrote:
> > On Thu 28-06-18 14:31:05, Paul E. McKenney wrote:
> > > On Thu, Jun 28, 2018 at 01:39:42PM +0200, Michal Hocko wrote:
[...]
> > > > Well, I am not really sure what is the objective
On Fri, Jun 29, 2018 at 11:04:19AM +0200, Michal Hocko wrote:
> On Thu 28-06-18 14:31:05, Paul E. McKenney wrote:
> > On Thu, Jun 28, 2018 at 01:39:42PM +0200, Michal Hocko wrote:
> > > On Wed 27-06-18 07:31:25, Paul E. McKenney wrote:
> > > > On Wed, Jun 27, 2018 at 09:22:07AM +0200, Michal Hocko
On Thu 28-06-18 14:31:05, Paul E. McKenney wrote:
> On Thu, Jun 28, 2018 at 01:39:42PM +0200, Michal Hocko wrote:
> > On Wed 27-06-18 07:31:25, Paul E. McKenney wrote:
> > > On Wed, Jun 27, 2018 at 09:22:07AM +0200, Michal Hocko wrote:
> > > > On Tue 26-06-18 10:03:45, Paul E. McKenney wrote:
> > >
On Thu, Jun 28, 2018 at 01:39:42PM +0200, Michal Hocko wrote:
> On Wed 27-06-18 07:31:25, Paul E. McKenney wrote:
> > On Wed, Jun 27, 2018 at 09:22:07AM +0200, Michal Hocko wrote:
> > > On Tue 26-06-18 10:03:45, Paul E. McKenney wrote:
> > > [...]
> > > > 3. Something else?
> > >
> > > How ha
On Wed 27-06-18 07:31:25, Paul E. McKenney wrote:
> On Wed, Jun 27, 2018 at 09:22:07AM +0200, Michal Hocko wrote:
> > On Tue 26-06-18 10:03:45, Paul E. McKenney wrote:
> > [...]
> > > 3.Something else?
> >
> > How hard it would be to use a different API than oom notifiers? E.g. a
> > shrin
On Wed, Jun 27, 2018 at 09:22:07AM +0200, Michal Hocko wrote:
> On Tue 26-06-18 10:03:45, Paul E. McKenney wrote:
> [...]
> > 3. Something else?
>
> How hard it would be to use a different API than oom notifiers? E.g. a
> shrinker which just kicks all the pending callbacks if the reclaim
> priori
On Wed, Jun 27, 2018 at 07:52:23PM +0900, Tetsuo Handa wrote:
> On 2018/06/27 8:50, Paul E. McKenney wrote:
> > On Wed, Jun 27, 2018 at 05:10:48AM +0900, Tetsuo Handa wrote:
> >> As far as I can see,
> >>
> >> - atomic_set(&oom_callback_count, 1);
> >> + atomic_inc(&oom_callback_count);
> >>
> >>
On 2018/06/27 8:50, Paul E. McKenney wrote:
> On Wed, Jun 27, 2018 at 05:10:48AM +0900, Tetsuo Handa wrote:
>> As far as I can see,
>>
>> -atomic_set(&oom_callback_count, 1);
>> +atomic_inc(&oom_callback_count);
>>
>> should be sufficient.
>
> I don't see how that helps. For example, supp
On Tue 26-06-18 10:03:45, Paul E. McKenney wrote:
[...]
> 3.Something else?
How hard it would be to use a different API than oom notifiers? E.g. a
shrinker which just kicks all the pending callbacks if the reclaim
priority reaches low values (e.g. 0)?
--
Michal Hocko
SUSE Labs
On Wed, Jun 27, 2018 at 05:10:48AM +0900, Tetsuo Handa wrote:
> On 2018/06/27 2:03, Paul E. McKenney wrote:
> > There are a lot of ways it could be made concurrency safe. If you need
> > me to do this, please do let me know.
> >
> > That said, the way it is now written, if you invoke rcu_oom_noti
On 2018/06/27 2:03, Paul E. McKenney wrote:
> There are a lot of ways it could be made concurrency safe. If you need
> me to do this, please do let me know.
>
> That said, the way it is now written, if you invoke rcu_oom_notify()
> twice in a row, the second invocation will wait until the memory
On Thu, Jun 21, 2018 at 08:27:41PM +0900, Tetsuo Handa wrote:
> On 2018/06/21 7:36, David Rientjes wrote:
> >> @@ -1010,6 +1010,33 @@ int unregister_oom_notifier(struct notifier_block
> >> *nb)
> >> EXPORT_SYMBOL_GPL(unregister_oom_notifier);
> >>
> >> /**
> >> + * try_oom_notifier - Try to re
On Mon 25-06-18 16:04:04, peter enderborg wrote:
> On 06/25/2018 03:07 PM, Michal Hocko wrote:
>
> > On Mon 25-06-18 15:03:40, peter enderborg wrote:
> >> On 06/20/2018 01:55 PM, Michal Hocko wrote:
> >>> On Wed 20-06-18 20:20:38, Tetsuo Handa wrote:
> Sleeping with oom_lock held can cause AB
On 06/25/2018 03:07 PM, Michal Hocko wrote:
> On Mon 25-06-18 15:03:40, peter enderborg wrote:
>> On 06/20/2018 01:55 PM, Michal Hocko wrote:
>>> On Wed 20-06-18 20:20:38, Tetsuo Handa wrote:
Sleeping with oom_lock held can cause AB-BA lockup bug because
__alloc_pages_may_oom() does not
On 06/25/2018 03:07 PM, Michal Hocko wrote:
> On Mon 25-06-18 15:03:40, peter enderborg wrote:
>> On 06/20/2018 01:55 PM, Michal Hocko wrote:
>>> On Wed 20-06-18 20:20:38, Tetsuo Handa wrote:
Sleeping with oom_lock held can cause AB-BA lockup bug because
__alloc_pages_may_oom() does not w
On Mon 25-06-18 15:03:40, peter enderborg wrote:
> On 06/20/2018 01:55 PM, Michal Hocko wrote:
> > On Wed 20-06-18 20:20:38, Tetsuo Handa wrote:
> >> Sleeping with oom_lock held can cause AB-BA lockup bug because
> >> __alloc_pages_may_oom() does not wait for oom_lock. Since
> >> blocking_notifier_
On 06/20/2018 01:55 PM, Michal Hocko wrote:
> On Wed 20-06-18 20:20:38, Tetsuo Handa wrote:
>> Sleeping with oom_lock held can cause AB-BA lockup bug because
>> __alloc_pages_may_oom() does not wait for oom_lock. Since
>> blocking_notifier_call_chain() in out_of_memory() might sleep, sleeping
>> wi
On Thu 21-06-18 20:27:41, Tetsuo Handa wrote:
[]
> On 2018/06/21 16:31, Michal Hocko wrote:
> > On Wed 20-06-18 15:36:45, David Rientjes wrote:
> > [...]
> >> That makes me think that "oom_notify_list" isn't very intuitive: it can
> >> free memory as a last step prior to oom kill. OOM notify,
On 2018/06/21 7:36, David Rientjes wrote:
>> @@ -1010,6 +1010,33 @@ int unregister_oom_notifier(struct notifier_block *nb)
>> EXPORT_SYMBOL_GPL(unregister_oom_notifier);
>>
>> /**
>> + * try_oom_notifier - Try to reclaim memory from OOM notifier list.
>> + *
>> + * Returns non-zero if notifier
On Wed 20-06-18 15:36:45, David Rientjes wrote:
[...]
> That makes me think that "oom_notify_list" isn't very intuitive: it can
> free memory as a last step prior to oom kill. OOM notify, to me, sounds
> like its only notifying some callbacks about the condition. Maybe
> oom_reclaim_list and t
On Wed, 20 Jun 2018, Tetsuo Handa wrote:
> Sleeping with oom_lock held can cause AB-BA lockup bug because
> __alloc_pages_may_oom() does not wait for oom_lock. Since
> blocking_notifier_call_chain() in out_of_memory() might sleep, sleeping
> with oom_lock held is currently an unavoidable problem.
On Wed 20-06-18 21:21:21, Tetsuo Handa wrote:
> On 2018/06/20 20:55, Michal Hocko wrote:
> > On Wed 20-06-18 20:20:38, Tetsuo Handa wrote:
> >> Sleeping with oom_lock held can cause AB-BA lockup bug because
> >> __alloc_pages_may_oom() does not wait for oom_lock. Since
> >> blocking_notifier_call_c
On 2018/06/20 20:55, Michal Hocko wrote:
> On Wed 20-06-18 20:20:38, Tetsuo Handa wrote:
>> Sleeping with oom_lock held can cause AB-BA lockup bug because
>> __alloc_pages_may_oom() does not wait for oom_lock. Since
>> blocking_notifier_call_chain() in out_of_memory() might sleep, sleeping
>> with
On Wed 20-06-18 20:20:38, Tetsuo Handa wrote:
> Sleeping with oom_lock held can cause AB-BA lockup bug because
> __alloc_pages_may_oom() does not wait for oom_lock. Since
> blocking_notifier_call_chain() in out_of_memory() might sleep, sleeping
> with oom_lock held is currently an unavoidable probl
Sleeping with oom_lock held can cause AB-BA lockup bug because
__alloc_pages_may_oom() does not wait for oom_lock. Since
blocking_notifier_call_chain() in out_of_memory() might sleep, sleeping
with oom_lock held is currently an unavoidable problem.
As a preparation for not to sleep with oom_lock h
34 matches
Mail list logo