linux-serial.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: Ivo Sieben <meltedpianoman@gmail.com>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	linux-serial@vger.kernel.org, Alan Cox <alan@linux.intel.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Oleg Nesterov <oleg@redhat.com>
Subject: Re: [REPOST] RFC: sched: Prevent wakeup to enter critical section needlessly
Date: Tue, 09 Oct 2012 16:15:04 +0200	[thread overview]
Message-ID: <1349792104.7880.41.camel@twins> (raw)
In-Reply-To: <m2r4p7u5pk.fsf@firstfloor.org>

On Tue, 2012-10-09 at 06:37 -0700, Andi Kleen wrote:
> Ivo Sieben <meltedpianoman@gmail.com> writes:
> 
> > Check the waitqueue task list to be non empty before entering the critical
> > section. This prevents locking the spin lock needlessly in case the queue
> > was empty, and therefor also prevent scheduling overhead on a PREEMPT_RT
> > system.
> >
> > Signed-off-by: Ivo Sieben <meltedpianoman@gmail.com>
> > ---
> >
> >  REPOST:
> >  Request for comments:
> >  - Does this make any sense?
> 
> Looks good to me. Avoiding any spinlock is good.  I don't even think you
> need "careful", if you miss an update it was just as it happened a
> little later.

Yeah, so I've started looking at this several times, but never had the
time to actually think it through. I think I'll agree with you that
using the careful list empty check isn't needed.

In general there's already the race of doing a wakeup before the wait
and if the code using the waitqueue doesn't deal with that its already
broken, so in that respect you should be good, since you're simply
shifting the timing a little.

One thing you might need to consider is the memory ordering, will the
list_empty -- either careful or not -- observe the right list pointer,
or could it -- when racing with wait_event()/prepare_to_wait() --
observe a stale value. Or.. is that all already covered in on the use
site.

I started auditing a few users to see what they all assume, if they're
already broken and or if they would now be broken.. but like said, I
didn't get anywhere.


I'd like to see this patch/Changelog amended to at least cover these
points so that I feel all warm and fuzzy when I read it and not have to
think too hard ;-)

  reply	other threads:[~2012-10-09 14:15 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-24 13:06 [PATCH] RFC: sched: Prevent wakeup to enter critical section needlessly Ivo Sieben
2012-10-09 11:30 ` [REPOST] " Ivo Sieben
2012-10-09 13:37   ` Andi Kleen
2012-10-09 14:15     ` Peter Zijlstra [this message]
2012-10-09 15:17       ` Oleg Nesterov
2012-10-10 14:02         ` Andi Kleen
2012-10-18  8:30           ` [PATCH-v2] " Ivo Sieben
2012-10-25 10:12             ` [REPOST-v2] " Ivo Sieben
2012-11-19  7:30               ` Ivo Sieben
2012-11-19 10:20                 ` Preeti U Murthy
2012-11-19 15:10                 ` Oleg Nesterov
2012-11-19 15:34                   ` Ivo Sieben
2012-11-19 15:49                     ` Oleg Nesterov
2012-11-21 13:03                       ` Ivo Sieben
2012-11-21 13:47                         ` Alan Cox
2012-11-21 13:58                         ` Oleg Nesterov

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=1349792104.7880.41.camel@twins \
    --to=peterz@infradead.org \
    --cc=alan@linux.intel.com \
    --cc=andi@firstfloor.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=meltedpianoman@gmail.com \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).