Messages in this thread | | | From | David Laight <> | Subject | RE: [PATCH] net: tcp: Fix a PTO timing granularity issue | Date | Wed, 27 May 2015 11:36:42 +0000 |
| |
From: Of Ido Yariv > Sent: 26 May 2015 21:17 > The Tail Loss Probe RFC specifies that the PTO value should be set to > max(2 * SRTT, 10ms), where SRTT is the smoothed round-trip time. > > The PTO value is converted to jiffies, so the timer may expire > prematurely. > > This is especially problematic on systems in which HZ <= 100, so work > around this by setting the timeout to at least 2 jiffies on such > systems. > > The 10ms figure was originally selected based on tests performed with > the current implementation and HZ = 1000. Thus, leave the behavior on > systems with HZ > 100 unchanged. > > Signed-off-by: Ido Yariv <idox.yariv@intel.com> > --- > net/ipv4/tcp_output.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c > index 534e5fd..5321df8 100644 > --- a/net/ipv4/tcp_output.c > +++ b/net/ipv4/tcp_output.c > @@ -2208,6 +2208,9 @@ bool tcp_schedule_loss_probe(struct sock *sk) > timeout = max_t(u32, timeout, > (rtt + (rtt >> 1) + TCP_DELACK_MAX)); > timeout = max_t(u32, timeout, msecs_to_jiffies(10)); > +#if HZ <= 100 > + timeout = max_t(u32, timeout, 2); > +#endif
Why not: timeout = max_t(u32, timeout, max_t(u32, 2, msecs_to_jiffies(10))); I think the RH max_t() is a compile time constant.
You need 2 jiffies to guarantee a non-zero timeout. Even if HZ=199 with a 'rounding down' msecs_to_jiffies() you get 1 jiffy and a possible immediate timeout.
There are probably other places where msecs_to_jiffies() better not return 1.
David
| |