Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934090AbdCXLRK (ORCPT ); Fri, 24 Mar 2017 07:17:10 -0400 Received: from mail-pg0-f67.google.com ([74.125.83.67]:34383 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751421AbdCXLRD (ORCPT ); Fri, 24 Mar 2017 07:17:03 -0400 Message-ID: <1490354210.9687.44.camel@edumazet-glaptop3.roam.corp.google.com> Subject: Re: [net-next PATCH v2 5/8] net: Track start of busy loop instead of when it should end From: Eric Dumazet To: Alexander Duyck Cc: Netdev , "linux-kernel@vger.kernel.org" , "Samudrala, Sridhar" , Eric Dumazet , David Miller , Linux API Date: Fri, 24 Mar 2017 04:16:50 -0700 In-Reply-To: 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> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 832 Lines: 19 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 ?