From: Oleg Nesterov <oleg@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: Imre Deak <imre.deak@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Dave Jones <davej@redhat.com>,
David Howells <dhowells@redhat.com>, Jens Axboe <axboe@kernel.dk>,
Linus Torvalds <torvalds@linux-foundation.org>,
Lukas Czerner <lczerner@redhat.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] wait: fix false timeouts when using wait_event_timeout()
Date: Thu, 6 Jun 2013 20:47:03 +0200 [thread overview]
Message-ID: <20130606184703.GA29312@redhat.com> (raw)
In-Reply-To: <20130606014507.GR10693@mtj.dyndns.org>
Hi Tejun,
On 06/05, Tejun Heo wrote:
>
> Heh, yeah, this looks good to me and a lot better than trying to do
> the same thing over and over again and ending up with subtle
> differences.
Yes, this is the goal. Of course we could fix wait_event_timout() and
wait_event_interruptible_timeout() without unification, but this would
add more copy-and-paste.
> > Hmm. I compiled the kernel with the patch below,
> >
> > $ size vmlinux
> > text data bss dec hex filename
> > - 4978601 2935080 10104832 18018513 112f0d1 vmlinux
> > + 4977769 2930984 10104832 18013585 112dd91 vmlinux
>
> Nice. Provided you went over assembly outputs of at least some
> combinations,
I did, and that is why I am surprized by the numbers above.
Yes, gcc optimizes out the unwanted checks but the generated code
differs, of course. And sometimes the difference looks "random" to me.
Simplest example:
extern wait_queue_head_t WQ;
extern int COND;
void we(void)
{
wait_event(WQ, COND);
}
before:
we:
pushq %rbp #
movq %rsp, %rbp #,
pushq %rbx #
subq $56, %rsp #,
call mcount
movl COND(%rip), %edx # COND,
testl %edx, %edx #
jne .L5 #,
leaq -64(%rbp), %rbx #, tmp66
movq $0, -64(%rbp) #, __wait
movq $autoremove_wake_function, -48(%rbp) #, __wait.func
#APP
# 14 "/home/tmp/K/misc/arch/x86/include/asm/current.h" 1
movq %gs:current_task,%rax #, pfo_ret__
# 0 "" 2
#NO_APP
movq %rax, -56(%rbp) # pfo_ret__, __wait.private
leaq 24(%rbx), %rax #, tmp61
movq %rax, -40(%rbp) # tmp61, __wait.task_list.next
movq %rax, -32(%rbp) # tmp61, __wait.task_list.prev
.p2align 4,,10
.p2align 3
.L4:
movl $2, %edx #,
movq %rbx, %rsi # tmp66,
movq $WQ, %rdi #,
call prepare_to_wait #
movl COND(%rip), %eax # COND,
testl %eax, %eax #
jne .L3 #,
call schedule #
jmp .L4 #
.p2align 4,,10
.p2align 3
.L3:
movq %rbx, %rsi # tmp66,
movq $WQ, %rdi #,
call finish_wait #
.L5:
addq $56, %rsp #,
popq %rbx #
leave
ret
after:
we:
pushq %rbp #
movq %rsp, %rbp #,
pushq %rbx #
subq $56, %rsp #,
call mcount
movl COND(%rip), %edx # COND,
testl %edx, %edx #
jne .L5 #,
leaq -64(%rbp), %rbx #, tmp66
movq $0, -64(%rbp) #, __wait
movq $autoremove_wake_function, -48(%rbp) #, __wait.func
#APP
# 14 "/home/tmp/K/misc/arch/x86/include/asm/current.h" 1
movq %gs:current_task,%rax #, pfo_ret__
# 0 "" 2
#NO_APP
movq %rax, -56(%rbp) # pfo_ret__, __wait.private
leaq 24(%rbx), %rax #, tmp61
movq %rax, -40(%rbp) # tmp61, __wait.task_list.next
movq %rax, -32(%rbp) # tmp61, __wait.task_list.prev
.p2align 4,,10
.p2align 3
.L4:
movl $2, %edx #,
movq %rbx, %rsi # tmp66,
movq $WQ, %rdi #,
call prepare_to_wait #
movl COND(%rip), %eax # COND,
testl %eax, %eax #
je .L3 #,
movq %rbx, %rsi # tmp66,
movq $WQ, %rdi #,
call finish_wait #
jmp .L5 #
.p2align 4,,10
.p2align 3
.L3:
call schedule #
.p2align 4,,8
.p2align 3
jmp .L4 #
.p2align 4,,10
.p2align 3
.L5:
addq $56, %rsp #,
popq %rbx #
leave
.p2align 4,,4
.p2align 3
ret
As you can see, with this patch gcc generates a bit more code. But
only because reorderes finish_wait() and inserts the additional nops,
otherwise code the same. I think this difference is not "reliable"
and can be ignored.
But, the code like "return wait_even_timeout(true, non_const_timeout)"
really generates more code and this is correct: the patch tries to fix
the bug (at least I think this is a bug) and the additional code ensures
that __ret != 0.
> Reviewed-by: Tejun Heo <tj@kernel.org>
Thanks! I'll send this patch soon.
Oleg.
next prev parent reply other threads:[~2013-06-06 18:51 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-04 19:28 [PATCH] wait: fix false timeouts when using wait_event_timeout() Oleg Nesterov
2013-06-04 21:35 ` Imre Deak
2013-06-04 21:40 ` Imre Deak
2013-06-05 16:37 ` Oleg Nesterov
2013-06-05 19:07 ` Oleg Nesterov
2013-06-06 1:45 ` Tejun Heo
2013-06-06 18:47 ` Oleg Nesterov [this message]
-- strict thread matches above, loose matches on Subject: below --
2013-05-02 8:58 Imre Deak
2013-05-02 9:36 ` Daniel Vetter
2013-05-07 23:12 ` Andrew Morton
2013-05-08 9:49 ` Imre Deak
2013-05-02 10:29 ` David Howells
2013-05-02 12:02 ` Imre Deak
2013-05-02 12:13 ` Daniel Vetter
2013-05-02 12:23 ` Jens Axboe
2013-05-02 12:29 ` David Howells
2013-05-02 12:34 ` Imre Deak
2013-05-02 12:54 ` Jens Axboe
2013-05-02 13:56 ` Imre Deak
2013-05-02 14:04 ` Daniel Vetter
2013-05-02 12:29 ` David Howells
2013-05-02 12:35 ` Jens Axboe
2013-05-02 19:56 ` Imre Deak
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=20130606184703.GA29312@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=daniel.vetter@ffwll.ch \
--cc=davej@redhat.com \
--cc=dhowells@redhat.com \
--cc=imre.deak@intel.com \
--cc=lczerner@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=tj@kernel.org \
--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