From: David Howells <dhowells@redhat.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: dhowells@redhat.com, linux-fsdevel@vger.kernel.org,
linux-afs@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 04/11] Add a function to start/reduce a timer
Date: Thu, 09 Nov 2017 00:33:21 +0000 [thread overview]
Message-ID: <8077.1510187601@warthog.procyon.org.uk> (raw)
In-Reply-To: <alpine.DEB.2.20.1710201359480.2908@nanos>
Thomas Gleixner <tglx@linutronix.de> wrote:
> > +extern int reduce_timer(struct timer_list *timer, unsigned long expires);
>
> For new timer functions we really should use the timer_xxxx()
> convention. The historic naming convention is horrible.
>
> Aside of that timer_reduce() is kinda ugly but I failed to come up with
> something reasonable as well.
reduce_timer() sounds snappier, probably because the verb is first, but I can
make it timer_reduce() if you prefer. Or maybe timer_advance() - though
that's less clear as to the direction.
> > + if (options & MOD_TIMER_REDUCE) {
> > + if (time_before_eq(timer->expires, expires))
> > + return 1;
> > + } else {
> > + if (timer->expires == expires)
> > + return 1;
> > + }
>
> This hurts the common networking optimzation case. Please keep that check
> first:
The way the code stands, it doesn't make much difference because compiler
optimises away the MOD_TIMER_REDUCE case for __mod_timer() and optimises away
the other branch for reduce_timer().
> if (timer->expires == expires)
> return 1;
>
> if ((options & MOD_TIMER_REDUCE) &&
> time_before(timer->expires, expires))
> return 1;
>
> Also please check whether it's more efficient code wise to have that option
> thing or if an additional 'bool reduce' argument cerates better code.
It's a constant passed into an inline function - gcc-7's optimiser copes with
that for x86_64 at least. mod_timer() contains:
0xffffffff810bb7a0 <+31>: cmpq $0x0,0x8(%rdi)
0xffffffff810bb7a5 <+36>: mov %rsi,%r12
0xffffffff810bb7a8 <+39>: mov %rdi,%rbx
0xffffffff810bb7ab <+42>: je 0xffffffff810bb829 <mod_timer+168>
0xffffffff810bb7ad <+44>: cmp 0x10(%rdi),%rsi
0xffffffff810bb7b1 <+48>: movl $0x1,-0x38(%rbp)
0xffffffff810bb7b8 <+55>: je 0xffffffff810bba9f <mod_timer+798>
and reduce_timer() contains:
0xffffffff810bbaed <+31>: cmpq $0x0,0x8(%rdi)
0xffffffff810bbaf2 <+36>: mov %rsi,%r13
0xffffffff810bbaf5 <+39>: mov %rdi,%rbx
0xffffffff810bbaf8 <+42>: je 0xffffffff810bbb9d <reduce_timer+207>
0xffffffff810bbafe <+48>: cmp 0x10(%rdi),%rsi
0xffffffff810bbb02 <+52>: mov $0x1,%r14d
0xffffffff810bbb08 <+58>: jns 0xffffffff810bbe23 <reduce_timer+853>
As you can see, the relevant jump instruction is JE in one and JNS in the
other.
If I make the change you suggest with the equality check being unconditional,
mod_timer() is unchanged and reduce_timer() then contains:
0xffffffff810bbaed <+31>: cmpq $0x0,0x8(%rdi)
0xffffffff810bbaf2 <+36>: mov %rsi,%r13
0xffffffff810bbaf5 <+39>: mov %rdi,%rbx
0xffffffff810bbaf8 <+42>: je 0xffffffff810bbba9 <reduce_timer+219>
0xffffffff810bbafe <+48>: mov 0x10(%rdi),%rax
0xffffffff810bbb02 <+52>: mov $0x1,%r14d
0xffffffff810bbb08 <+58>: cmp %rax,%rsi
0xffffffff810bbb0b <+61>: je 0xffffffff810bbe2f <reduce_timer+865>
0xffffffff810bbb11 <+67>: cmp %rax,%rsi
0xffffffff810bbb14 <+70>: jns 0xffffffff810bbe2f <reduce_timer+865>
which smacks of a missed optimisation, since timer_before_eq() covers the ==
case. Doing:
long diff = timer->expires - expires;
if (diff == 0)
return 1;
if (options & MOD_TIMER_REDUCE &&
diff <= 0)
return 1;
gets me the same code in mod_timer() and the following in reduce_timer():
0xffffffff810bbaed <+31>: cmpq $0x0,0x8(%rdi)
0xffffffff810bbaf2 <+36>: mov %rsi,%r13
0xffffffff810bbaf5 <+39>: mov %rdi,%rbx
0xffffffff810bbaf8 <+42>: je 0xffffffff810bbba3 <reduce_timer+213>
0xffffffff810bbafe <+48>: mov 0x10(%rdi),%rax
0xffffffff810bbb02 <+52>: mov $0x1,%r14d
0xffffffff810bbb08 <+58>: sub %rsi,%rax
0xffffffff810bbb0b <+61>: test %rax,%rax
0xffffffff810bbb0e <+64>: jle 0xffffffff810bbe29 <reduce_timer+859>
which is marginally better - though I think it could still be optimised
better by the compiler.
Actually, something that might increase efficiency overall is to make
add_timer() an inline and forego the check - but that's a separate matter.
Thanks,
David
next prev parent reply other threads:[~2017-11-09 0:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-01 15:40 [RFC PATCH 01/11] workqueue: Add a decrement-after-return and wake if 0 facility David Howells
2017-09-01 15:41 ` [RFC PATCH 02/11] refcount: Implement inc/decrement-and-return functions David Howells
2017-09-01 16:42 ` Peter Zijlstra
2017-09-01 21:15 ` David Howells
2017-09-01 21:50 ` Peter Zijlstra
2017-09-01 22:03 ` Peter Zijlstra
2017-09-01 22:51 ` David Howells
2017-09-04 7:30 ` Peter Zijlstra
2017-09-04 15:36 ` Christoph Hellwig
2017-09-04 16:08 ` David Howells
2017-09-05 6:45 ` Christoph Hellwig
2017-09-01 15:41 ` [RFC PATCH 03/11] Pass mode to wait_on_atomic_t() action funcs and provide default actions David Howells
2017-09-01 15:41 ` [RFC PATCH 04/11] Add a function to start/reduce a timer David Howells
2017-10-20 12:20 ` Thomas Gleixner
2017-11-09 0:33 ` David Howells [this message]
2017-09-01 15:41 ` [RFC PATCH 05/11] afs: Lay the groundwork for supporting network namespaces David Howells
2017-09-01 15:41 ` [RFC PATCH 06/11] afs: Add some protocol defs David Howells
2017-09-01 15:41 ` [RFC PATCH 07/11] afs: Update the cache index structure David Howells
2017-09-01 15:41 ` [RFC PATCH 08/11] afs: Keep and pass sockaddr_rxrpc addresses rather than in_addr David Howells
2017-09-01 15:41 ` [RFC PATCH 09/11] afs: Allow IPv6 address specification of VL servers David Howells
2017-09-01 15:42 ` [RFC PATCH 10/11] afs: Overhaul cell database management David Howells
2017-09-01 15:42 ` [RFC PATCH 11/11] afs: Retry rxrpc calls with address rotation on network error David Howells
2017-09-01 15:52 ` [RFC PATCH 00/11] AFS: Namespacing part 1 David Howells
2017-09-05 13:29 ` [RFC PATCH 01/11] workqueue: Add a decrement-after-return and wake if 0 facility Tejun Heo
2017-09-05 14:50 ` David Howells
2017-09-06 14:51 ` Tejun Heo
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=8077.1510187601@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=linux-afs@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
/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