On Tue, 17 Mar 2020, Tetsuo Handa wrote:
> > if (!fatal_signal_pending(current))
> > schedule_timeout_killable(1);
> >
> > So we don't have this reliance on all other memory chargers to yield when
> > their charge fails and there is no delay for victims themselves.
>
> I see. You want below functions for environments where current thread can
> fail to resume execution for long if current thread once reschedules (e.g.
> UP kernel, many threads contended on one CPU).
>
> /*
> * Give other threads CPU time, unless current thread was already killed.
> * Used when we prefer killed threads to continue execution (in a hope that
> * killed threads terminate quickly) over giving other threads CPU time.
> */
> signed long __sched schedule_timeout_killable_expedited(signed long timeout)
> {
> if (unlikely(fatal_signal_pending(current)))
> return timeout;
> return schedule_timeout_killable(timeout);
> }
>
I simply want the
if (!fatal_signal_pending(current))
schedule_timeout_killable(1);
after dropping oom_lock because I don't know that a generic function would
be useful outside of this single place. If it becomes a regular pattern,
for whatever reason, I think we can consider a new schedule_timeout
variant.
> /*
> * Latency reduction via explicit rescheduling in places that are safe,
> * but becomes no-op if current thread was already killed. Used when we
> * prefer killed threads to continue execution (in a hope that killed
> * threads terminate quickly) over giving other threads CPU time.
> */
> int cond_resched_expedited(void)
> {
> if (unlikely(fatal_signal_pending(current)))
> return 0;
> return cond_resched();
> }
>
> >
> > [ I'll still propose my change that adds cond_resched() to
> > shrink_node_memcgs() because we can see need_resched set for a
> > prolonged period of time without scheduling. ]
>
> As long as there is schedule_timeout_killable(), I'm fine with adding
> cond_resched() in other places.
>
Sounds good, thanks Tetsuo.
