All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hao Jia <jiahao.os@bytedance.com>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Peter Zijlstra <peterz@infradead.org>
Cc: mingo@redhat.com, juri.lelli@redhat.com,
	vincent.guittot@linaro.org, rostedt@goodmis.org,
	bsegall@google.com, mgorman@suse.de, bristot@redhat.com,
	linux-kernel@vger.kernel.org
Subject: Re: [External] Re: [PATCH] sched/core: Avoid obvious double update_rq_clock warning
Date: Thu, 21 Apr 2022 15:24:33 +0800	[thread overview]
Message-ID: <84f61791-8cf2-b955-5d71-1cab15129ab2@bytedance.com> (raw)
In-Reply-To: <df0c4d87-68be-7aef-597f-043b3c7fea59@arm.com>



On 2022/4/21 Dietmar Eggemann wrote:
> On 20/04/2022 10:29, Hao Jia wrote:
>> On 4/19/22 6:48 PM, Peter Zijlstra wrote:
>>> On Mon, Apr 18, 2022 at 05:09:29PM +0800, Hao Jia wrote:
> 
> [...]
> 
>>> I'm really not sure about this part though. This is a bit of a mess. The
>>> balancer doesn't really need the pinning stuff. I realize you did that
>>> because we got the clock annotation mixed up with that, but urgh.
>>>
>>> Basically we want double_rq_lock() / double_lock_balance() to clear
>>> RQCF_UPDATED, right? Perhaps do that directly?
>>>
>>> (maybe with an inline helper and a wee comment?)
>>>
>>> The only immediate problem with this would appear to be that
>>> _double_rq_lock() behaves differently when it returns 0. Not sure that
>>> matters.
>>>
>>> Hmm?
>>
>> Thanks for your review comments.
>> As you have prompted, the WARN_DOUBLE_CLOCK warning is still triggered
>> when _double_rq_lock() returns 0.
>> Please review the solution below, and based on your review, I will
>> submit the v2 patch as soon as possible.
>> Thanks.
> 
> 
> [...]
> 
> Maybe something like this:
> 
> -->8--
> 
> From: Dietmar Eggemann <dietmar.eggemann@arm.com>
> Date: Wed, 20 Apr 2022 11:12:10 +0200
> Subject: [PATCH] sched/core: Clear RQCF_UPDATED in _double_lock_balance() &
>   double_rq_lock()
> 
> Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
> ---
>   kernel/sched/core.c  |  6 +++---
>   kernel/sched/sched.h | 20 ++++++++++++++++----
>   2 files changed, 19 insertions(+), 7 deletions(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 068c088e9584..f4cfe7eea861 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -610,10 +610,10 @@ void double_rq_lock(struct rq *rq1, struct rq *rq2)
>   		swap(rq1, rq2);
>   
>   	raw_spin_rq_lock(rq1);
> -	if (__rq_lockp(rq1) == __rq_lockp(rq2))
> -		return;
> +	if (__rq_lockp(rq1) != __rq_lockp(rq2))
> +		raw_spin_rq_lock_nested(rq2, SINGLE_DEPTH_NESTING);
>   
> -	raw_spin_rq_lock_nested(rq2, SINGLE_DEPTH_NESTING);
> +	rq_clock_clear_update(rq1, rq2);
>   }
>   #endif
>   
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index 58263f90c559..3a77b10d7cc4 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -2515,6 +2515,16 @@ static inline bool rq_order_less(struct rq *rq1, struct rq *rq2)
>   
>   extern void double_rq_lock(struct rq *rq1, struct rq *rq2);
>   
> +#ifdef CONFIG_SCHED_DEBUG
> +static inline void rq_clock_clear_update(struct rq *rq1, struct rq *rq2)
> +{
> +	rq1->clock_update_flags &= (RQCF_REQ_SKIP|RQCF_ACT_SKIP);
> +	rq2->clock_update_flags &= (RQCF_REQ_SKIP|RQCF_ACT_SKIP);
> +}
> +#else
> +static inline void rq_clock_clear_update(struct rq *rq1, struct rq *rq2) {}
> +#endif
> +
>   #ifdef CONFIG_PREEMPTION
>   
>   /*
> @@ -2549,14 +2559,15 @@ static inline int _double_lock_balance(struct rq *this_rq, struct rq *busiest)
>   	__acquires(busiest->lock)
>   	__acquires(this_rq->lock)
>   {
> -	if (__rq_lockp(this_rq) == __rq_lockp(busiest))
> -		return 0;
> -
> -	if (likely(raw_spin_rq_trylock(busiest)))
> +	if (__rq_lockp(this_rq) == __rq_lockp(busiest) ||
> +	    likely(raw_spin_rq_trylock(busiest))) {
> +		rq_clock_clear_update(this_rq, busiest);
>   		return 0;
> +	}
>   
>   	if (rq_order_less(this_rq, busiest)) {
>   		raw_spin_rq_lock_nested(busiest, SINGLE_DEPTH_NESTING);
> +		rq_clock_clear_update(this_rq, busiest);
>   		return 0;
>   	}
>   
> @@ -2650,6 +2661,7 @@ static inline void double_rq_lock(struct rq *rq1, struct rq *rq2)
>   	BUG_ON(rq1 != rq2);
>   	raw_spin_rq_lock(rq1);
>   	__acquire(rq2->lock);	/* Fake it out ;) */
> +	rq_clock_clear_update(rq1, rq2);

Thanks for your review.
This is very helpful to me.
If CONFIG_SMP is not enabled, should we just clear the RQCF_UPDATED of 
one of rq1 and q2?

like this:
rq1->clock_update_flags &= (RQCF_REQ_SKIP|RQCF_ACT_SKIP);

Thanks.

>   }
>   
>   /*

  reply	other threads:[~2022-04-21  7:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-18  9:09 [PATCH] sched/core: Avoid obvious double update_rq_clock warning Hao Jia
2022-04-19 10:48 ` Peter Zijlstra
2022-04-20  8:29   ` [External] " Hao Jia
2022-04-20 19:11     ` Dietmar Eggemann
2022-04-21  7:24       ` Hao Jia [this message]
2022-04-21 10:32         ` Dietmar Eggemann
2022-04-21 12:30 ` Dietmar Eggemann
2022-04-21 13:15   ` [External] " Hao Jia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84f61791-8cf2-b955-5d71-1cab15129ab2@bytedance.com \
    --to=jiahao.os@bytedance.com \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.