From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 14:04:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 72C113B7; Fri, 23 Aug 2013 14:04:06 +0000 (UTC) (envelope-from vitja.makarov@gmail.com) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0BD5129DC; Fri, 23 Aug 2013 14:04:05 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id hf12so437975vcb.41 for ; Fri, 23 Aug 2013 07:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4bcNgb7+5Zsf+X9znv3XycLqhRLZyldMzHilKnrvN8I=; b=xsqI6f3CPZ4wnzRGEDLsuCgIBNw15QOQdwZrK7+9X1HfkSvYxGnHf0iElzKuPuykOo VJyUYVJJkpMPsZDh7jUdJc/MWP0yjM8Sp7e6c4blqsR06s4Aau5Qb04CPuqVjnO5AOn8 VQICy8+B05Hb1NbNjqvQqPG/YaTmAFIn+uyzGLH2PlY32FwX/405vWPzupuKqkNxbwFB WrTexwnAmBFqoRojPyED3wlcxZcutO6AKi+FDRhA7uqmBLxFQIKsV1/hJzjf9ikUTTZX 0YPeTSFxHNqwpvctUibYjqcedFqa+o3oxcaJObMCmrIBJ0g0RikPf4nFCSa+J2UX0A2Z Xf1g== MIME-Version: 1.0 X-Received: by 10.58.155.6 with SMTP id vs6mr168814veb.32.1377266645258; Fri, 23 Aug 2013 07:04:05 -0700 (PDT) Received: by 10.52.27.51 with HTTP; Fri, 23 Aug 2013 07:04:05 -0700 (PDT) In-Reply-To: References: <201308221408.08203.jhb@freebsd.org> <201308230945.28701.jhb@freebsd.org> Date: Fri, 23 Aug 2013 18:04:05 +0400 Message-ID: Subject: Re: Question about socket timeouts From: Vitja Makarov To: Davide Italiano Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Fri, 23 Aug 2013 15:23:55 +0000 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 14:04:06 -0000 2013/8/23 Davide Italiano : > On Fri, Aug 23, 2013 at 3:45 PM, John Baldwin wrote: >> On Friday, August 23, 2013 2:27:58 am Vitja Makarov wrote: >>> 2013/8/22 John Baldwin : >>> > On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote: >>> >> 2013/8/21 John Baldwin : >>> >> > On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote: >>> >> >> On Mon, 19 Aug 2013, Adrian Chadd wrote: >>> >> >> >>> >> >> > Yes! Please file a PR! >>> >> >> >>> >> >> This sorta implies that both are acceptable (although, >>> >> >> the Linux behavior seems more desirable). >>> >> >> >>> >> >> http://austingroupbugs.net/view.php?id=369 >>> >> > >>> >> > No, that says "round up", so it does mean that the requested timeout >>> >> > should be the minimum amount slept. tvtohz() does this. Really odd >>> >> > that the socket code is using its own version of this rather than >>> >> > tvtohz(). >>> >> > >>> >> > Oh, I bet this just predates tvtohz(). Interesting that it keeps getting >>> >> > bug fixes in its history that simply using tvtohz() would have solved. >>> >> > >>> >> > Try this: >>> >> > >>> >> > Index: uipc_socket.c >>> >> > =================================================================== >>> >> > --- uipc_socket.c (revision 254570) >>> >> > +++ uipc_socket.c (working copy) >>> >> > @@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct sockopt *sopt) >>> >> > if (error) >>> >> > goto bad; >>> >> > >>> >> > - /* assert(hz > 0); */ >>> >> > if (tv.tv_sec < 0 || tv.tv_sec > INT_MAX / hz || >>> >> > tv.tv_usec < 0 || tv.tv_usec >= 1000000) { >>> >> > error = EDOM; >>> >> > goto bad; >>> >> > } >>> >> > - /* assert(tick > 0); */ >>> >> > - /* assert(ULONG_MAX - INT_MAX >= 1000000); */ >>> >> > - val = (u_long)(tv.tv_sec * hz) + tv.tv_usec / tick; >>> >> > - if (val > INT_MAX) { >>> >> > + val = tvtohz(&tv); >>> >> > + if (val == INT_MAX) { >>> >> > error = EDOM; >>> >> > goto bad; >>> >> > } >>> >> > - if (val == 0 && tv.tv_usec != 0) >>> >> > - val = 1; >>> >> > >>> >> > switch (sopt->sopt_name) { >>> >> > case SO_SNDTIMEO: >>> >> > >>> >> >>> >> That must help. But I want to see the issue solved in the next >>> >> release. I can't apply patch to the production system. Btw in >>> >> production environment we have kern.hz set to 1000 so it's not a >>> >> problem there. >>> > >>> > Can you test this in some way in a test environment? >>> > >>> >>> Ok, sorry for posting out of the list. >>> >>> Simple test program is attached. Without your patch timeout expires in >>> about 20ms. With it it's ~40ms. >>> >>> 40 instead of 30 is beacuse of odd tick added by tvtohz(). >> >> Ok, thanks. tvtohz() will be good to MFC (and I will do that), but for >> HEAD I think we can fix this to use a precise timeout. I've cc'd davide@ >> so he can take a look at that. >> >> -- >> John Baldwin > > Hi, > I think I can switch this code to new timeout KPI, but this will > require the timeout field of 'struct sockbuf' to be changed from 'int' > to 'sbintime_t' which breaks binary compatibility. Do you have any > strong objections about this? If any, I would like this to happen ABI > freeze, so it looks like this is the right moment. > I think that for socket's timeouts it's ok to have a HZ-precision. It would be much more important to implement high-precision timeouts for select() and friends, if it's not done yet (sorry I'm running 9.1). -- vitja.