Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936750AbdCXPsr (ORCPT ); Fri, 24 Mar 2017 11:48:47 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:36839 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936377AbdCXPsV (ORCPT ); Fri, 24 Mar 2017 11:48:21 -0400 MIME-Version: 1.0 In-Reply-To: <1490354210.9687.44.camel@edumazet-glaptop3.roam.corp.google.com> References: <20170323211820.12615.88907.stgit@localhost.localdomain> <20170323213742.12615.85793.stgit@localhost.localdomain> <1490318682.9687.22.camel@edumazet-glaptop3.roam.corp.google.com> <1490329655.9687.33.camel@edumazet-glaptop3.roam.corp.google.com> <1490354210.9687.44.camel@edumazet-glaptop3.roam.corp.google.com> From: Alexander Duyck Date: Fri, 24 Mar 2017 08:48:13 -0700 Message-ID: Subject: Re: [net-next PATCH v2 5/8] net: Track start of busy loop instead of when it should end To: Eric Dumazet Cc: Netdev , "linux-kernel@vger.kernel.org" , "Samudrala, Sridhar" , Eric Dumazet , David Miller , Linux API Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1538 Lines: 30 On Fri, Mar 24, 2017 at 4:16 AM, Eric Dumazet wrote: > On Thu, 2017-03-23 at 22:55 -0700, Alexander Duyck wrote: > >> Right, but time_after assumes roll over. When you are using a time >> value based off of local_clock() >> 10, you don't ever roll over when >> you do addition. Just the clock rolls over. At least on 64 bit >> systems. >> >> So if local time approaches something like all 1's, and we have >> shifted it by 10 it is then the max it can ever reach is >> 0x003FFFFFFFFFFFFF. I can add our loop time to that and it won't roll >> over. In the mean time the busy_loop_us_ can never exceed whatever I >> added to that so we are now locked into a loop. I realize I am >> probably being pedantic, and it will have an exceedingly small rate of >> occurrence, but it is still an issue. > > Do you realize that a 64bit clock wont rollover before the host has > reached 584 years of uptime ? Yeah, that is what I meant by "probably being pedantic". I was being a too much of a perfectionist. So I can work with the ">> 10" approach. The only thing I think I may still want to change is that on 32b systems I will still use the do_procintvec_minmax for busy_poll and busy_read to prevent us from inputting values less than 0. For 64b systems we can do_procuintvec. It isn't so much that I don't trust root, it is just that we didn't really document the ranges anywhere for this so I figure if we at least lock that down to the usable ranges since root may not be aware of the implementation details.