All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: xuhaifeng <xuhaifeng@oppo.com>
Cc: mingo@redhat.com, juri.lelli@redhat.com,
	dietmar.eggemann@arm.com, rostedt@goodmis.org,
	bsegall@google.com, mgorman@suse.de, bristot@redhat.com,
	linux-kernel@vger.kernel.org,
	Frederic Weisbecker <fweisbec@gmail.com>
Subject: Re: [PATCH] sched: optimize __cond_resched_lock()
Date: Tue, 21 Dec 2021 13:01:22 +0100	[thread overview]
Message-ID: <YcHCEm/6AL0DQrv7@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <YcGnvDEYBwOiV0cR@hirez.programming.kicks-ass.net>

On Tue, Dec 21, 2021 at 11:09:00AM +0100, Peter Zijlstra wrote:
> On Tue, Dec 21, 2021 at 09:52:28AM +0100, Peter Zijlstra wrote:
> > On Tue, Dec 21, 2021 at 03:23:16PM +0800, xuhaifeng wrote:
> > > if the kernel is preemptible(CONFIG_PREEMPTION=y), schedule()may be
> > > called twice, once via spin_unlock, once via preempt_schedule_common.
> > > 
> > > we can add one conditional, check TIF_NEED_RESCHED flag again,
> > > to avoid this.
> > 
> > You can also make it more similar to __cond_resched() instead of making
> > it more different.
> 
> Bah, sorry, had to wake up first :/
> 
> cond_resched_lock still needs to exist for PREEMPT because locks won't
> magically release themselves.
> 
> Still don't much like the patch though, how's this work for you?
> 
> That's arguably the right thing to do work PREEMPT_DYNAMIC too.

Duh, those would need cond_resched() proper, clearly I should just give
up and call it a holiday already..

  reply	other threads:[~2021-12-21 12:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-21  7:23 [PATCH] sched: optimize __cond_resched_lock() xuhaifeng
2021-12-21  8:52 ` Peter Zijlstra
2021-12-21 10:09   ` Peter Zijlstra
2021-12-21 12:01     ` Peter Zijlstra [this message]
2021-12-21 13:30     ` xuhaifeng
2022-01-18 11:18     ` [tip: sched/urgent] sched: Avoid double preemption in __cond_resched_*lock*() tip-bot2 for Peter Zijlstra

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=YcHCEm/6AL0DQrv7@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=fweisbec@gmail.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=xuhaifeng@oppo.com \
    /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.