mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ingo Molnar <mingo@kernel.org>, Andi Kleen <ak@linux.intel.com>,
	Peter Anvin <hpa@zytor.com>, Mike Galbraith <bitbucket@online.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Arjan van de Ven <arjan@linux.intel.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>
Subject: Re: [PATCH 0/7] preempt_count rework -v2
Date: Tue, 10 Sep 2013 18:45:19 +0200	[thread overview]
Message-ID: <20130910164519.GL31370@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <CA+55aFwmEQeF+PtM7cuaQ8OkuTS=R4JJ61Wwfv8u-Svo-V3KwQ@mail.gmail.com>

On Tue, Sep 10, 2013 at 09:34:52AM -0700, Linus Torvalds wrote:
> On Tue, Sep 10, 2013 at 6:56 AM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > +static __always_inline bool __preempt_count_dec_and_test(void)
> > +{
> > +       unsigned char c;
> > +
> > +       asm ("decl " __percpu_arg(0) "; sete %1"
> > +                       : "+m" (__preempt_count), "=qm" (c));
> > +
> > +       return c != 0;
> > +}
> >
> > And that's where the sete and test originates from.
> 
> We could make this use "asm goto" instead.
> 
> An "asm goto" cannot have outputs, but this particular one doesn't
> _need_ outputs. You could mark the preempt_count memory as an input,
> and then have a memory clobber. I think you need the memory clobber
> anyway for that preempt-count thing.
> 
> So I _think_ something like
> 
> static __always_inline bool __preempt_count_dec_and_test(void)
> {
>        asm goto("decl " __percpu_arg(0) "\n\t"
>                 "je %l[became_zero]"
>                        : :"m" (__preempt_count):"memory":became_zero);
>        return 0;
> became_zero:
>        return 1;
> }

The usage site:

#define preempt_enable() \
do { \
	barrier(); \
	if (unlikely(preempt_count_dec_and_test())) \
		__preempt_schedule(); \
} while (0)

Already includes the barrier explicitly, so do we still need the memory
clobber in that asm goto thing?

That said, your change results in:

  ffffffff8106f420 <kick_process>:
  ffffffff8106f420:       55                      push   %rbp
  ffffffff8106f421:       65 ff 04 25 e0 b7 00    incl   %gs:0xb7e0
  ffffffff8106f428:       00 
  ffffffff8106f429:       48 89 e5                mov    %rsp,%rbp
  ffffffff8106f42c:       48 8b 47 08             mov    0x8(%rdi),%rax
  ffffffff8106f430:       8b 50 18                mov    0x18(%rax),%edx
  ffffffff8106f433:       65 8b 04 25 1c b0 00    mov    %gs:0xb01c,%eax
  ffffffff8106f43a:       00 
  ffffffff8106f43b:       39 c2                   cmp    %eax,%edx
  ffffffff8106f43d:       74 1b                   je     ffffffff8106f45a <kick_process+0x3a>
  ffffffff8106f43f:       89 d1                   mov    %edx,%ecx
  ffffffff8106f441:       48 c7 c0 00 2c 01 00    mov    $0x12c00,%rax
  ffffffff8106f448:       48 8b 0c cd a0 bc cb    mov    -0x7e344360(,%rcx,8),%rcx
  ffffffff8106f44f:       81 
  ffffffff8106f450:       48 3b bc 08 00 08 00    cmp    0x800(%rax,%rcx,1),%rdi
  ffffffff8106f457:       00 
  ffffffff8106f458:       74 26                   je     ffffffff8106f480 <kick_process+0x60>
* ffffffff8106f45a:       65 ff 0c 25 e0 b7 00    decl   %gs:0xb7e0
  ffffffff8106f461:       00 
* ffffffff8106f462:       74 0c                   je     ffffffff8106f470 <kick_process+0x50>
  ffffffff8106f464:       5d                      pop    %rbp
  ffffffff8106f465:       c3                      retq   
  ffffffff8106f466:       66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)
  ffffffff8106f46d:       00 00 00 
* ffffffff8106f470:       e8 9b b6 f9 ff          callq  ffffffff8100ab10 <___preempt_schedule>
  ffffffff8106f475:       5d                      pop    %rbp
  ffffffff8106f476:       c3                      retq   
  ffffffff8106f477:       66 0f 1f 84 00 00 00    nopw   0x0(%rax,%rax,1)
  ffffffff8106f47e:       00 00 
  ffffffff8106f480:       89 d7                   mov    %edx,%edi
  ffffffff8106f482:       ff 15 b8 e0 ba 00       callq  *0xbae0b8(%rip)        # ffffffff81c1d540 <smp_ops+0x20>
  ffffffff8106f488:       eb d0                   jmp    ffffffff8106f45a <kick_process+0x3a>
  ffffffff8106f48a:       66 0f 1f 44 00 00       nopw   0x0(%rax,%rax,1)


Which is indeed perfect. So should I go 'fix' the other _and_test()
functions we have to do this same thing?

  reply	other threads:[~2013-09-10 16:45 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-10 13:08 Peter Zijlstra
2013-09-10 13:08 ` [PATCH 1/7] sched: Introduce preempt_count accessor functions Peter Zijlstra
2013-09-10 13:08 ` [PATCH 2/7] sched: Add NEED_RESCHED to the preempt_count Peter Zijlstra
2013-09-11  1:59   ` Andy Lutomirski
2013-09-11  8:25     ` Peter Zijlstra
2013-09-11 11:06       ` Peter Zijlstra
2013-09-11 13:34         ` Mike Galbraith
2013-09-12  6:01           ` Mike Galbraith
2013-09-11 16:35         ` Andy Lutomirski
2013-09-11 18:05           ` Peter Zijlstra
2013-09-11 18:07             ` Andy Lutomirski
2013-09-11 11:14   ` Peter Zijlstra
2013-09-10 13:08 ` [PATCH 3/7] sched, arch: Create asm/preempt.h Peter Zijlstra
2013-09-10 13:08 ` [PATCH 4/7] sched: Create more preempt_count accessors Peter Zijlstra
2013-09-10 13:08 ` [PATCH 5/7] sched: Extract the basic add/sub preempt_count modifiers Peter Zijlstra
2013-09-10 13:08 ` [PATCH 6/7] sched, x86: Provide a per-cpu preempt_count implementation Peter Zijlstra
2013-09-10 13:27   ` Peter Zijlstra
2013-09-10 14:02   ` Eric Dumazet
2013-09-10 15:25     ` Peter Zijlstra
2013-09-10 16:48   ` Peter Zijlstra
2013-09-10 13:08 ` [PATCH 7/7] sched, x86: Optimize the preempt_schedule() call Peter Zijlstra
2013-09-10 13:42   ` Ingo Molnar
2013-09-10 13:55     ` Jan Beulich
2013-09-10 14:25       ` Ingo Molnar
2013-09-10 13:51 ` [PATCH 0/7] preempt_count rework -v2 Ingo Molnar
2013-09-10 13:56   ` Ingo Molnar
2013-09-10 15:14     ` Peter Zijlstra
2013-09-10 15:29     ` Arjan van de Ven
2013-09-10 15:35       ` Peter Zijlstra
2013-09-10 16:24       ` Linus Torvalds
2013-09-11 16:00         ` H. Peter Anvin
2013-09-10 16:34     ` Linus Torvalds
2013-09-10 16:45       ` Peter Zijlstra [this message]
2013-09-10 17:06         ` Linus Torvalds
2013-09-10 21:25           ` Peter Zijlstra
2013-09-10 21:43             ` Linus Torvalds
2013-09-10 21:51               ` H. Peter Anvin
2013-09-10 22:02                 ` Linus Torvalds
2013-09-10 22:06                   ` H. Peter Anvin
2013-09-11 13:13               ` Peter Zijlstra
2013-09-11 13:26                 ` Peter Zijlstra
2013-09-11 15:29                 ` H. Peter Anvin
2013-09-11 15:33                 ` Linus Torvalds
2013-09-11 18:59                   ` Peter Zijlstra
2013-09-11 23:02                     ` Linus Torvalds
2013-09-12  2:20                       ` Peter Zijlstra
2013-09-12  2:43                         ` Linus Torvalds
2013-09-12 11:51                           ` Peter Zijlstra
2013-09-12 12:25                             ` Ingo Molnar
2013-09-13  7:25                         ` Kevin Easton
2013-09-13  8:06                           ` 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=20130910164519.GL31370@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=ak@linux.intel.com \
    --cc=arjan@linux.intel.com \
    --cc=bitbucket@online.de \
    --cc=fweisbec@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome