Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2568730imm; Sun, 5 Aug 2018 07:11:11 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeOympFnk2lp5JyRbOvYdHM7KhzxQSlvWBl5TtmOys6kHa4rFq34RN4m4OPusSK490nbCyH X-Received: by 2002:a63:1c13:: with SMTP id c19-v6mr11122286pgc.332.1533478271527; Sun, 05 Aug 2018 07:11:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533478271; cv=none; d=google.com; s=arc-20160816; b=CLj5bQRicLEKja9ec7yfy9uP4IySMt2pF+6H1MEITKGIKL1gkkjOcVYAaAq3aGPg3Z nWNFmH/irNyVTi1K213J48hxLunkOFdfZMJ5oDbMU6DhBjjvfgK1I9H/6qlvvzSiaj25 C7TN5ZeCHFh14+KuUIOxl8tWYTYwwCInIkMJhes9m4qkxGgLUg9NbzY/jUedTFaqS9U5 Y5HzJGZDin8i/KmqdQbnp7cvbzf7tit6BbenKV17xMvy7kRRL21TVjg/cMaTxJiKyfZo IlXVigypuWCYYkC6KhzY+THApJuK4u4EGxHBy4Ril5PKmFn7cIojQeS3UukJBmdsmSTF fVnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=hpTpsNnGoUYlTv8VydFy68kiK6jQDv4hgRXhnwM4OHU=; b=nYo/ZamlsUp66mgeAYuzGUhFEuzPDP+/A6+3FQFDwgi2zNAcbqR0O7mUdHxtObV3oW Y7mujASKl3uLN6aOFYWMv3lJMk1xVs5dOtHqrVRItheG0R2coirmNL4DZIUQDby9XFIh 0MZlJ691zVM7niOh8cJBZCSW/IzJYCMYLoRW9sn3M4waxrNGLS9nswpjVM3xUyUWDBTq 7Vi6MtjIYnlxZff198hfu0126O0OYi3naWDa1vQRVIcNL2Lq/aErfFIcC2zdSiL/vGkv q36dtdZQfI0ReW/RFNM2+hHoghEgiLozw5/qjhnBMwC/zkQsBQ0ToquPumEP7hTKbOu2 JWog== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=mbIy2DLZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m3-v6si10147297pgr.108.2018.08.05.07.10.56; Sun, 05 Aug 2018 07:11:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=mbIy2DLZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726691AbeHEQOA (ORCPT + 99 others); Sun, 5 Aug 2018 12:14:00 -0400 Received: from mail-ua0-f194.google.com ([209.85.217.194]:39163 "EHLO mail-ua0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726204AbeHEQN7 (ORCPT ); Sun, 5 Aug 2018 12:13:59 -0400 Received: by mail-ua0-f194.google.com with SMTP id g18-v6so9371715uam.6; Sun, 05 Aug 2018 07:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hpTpsNnGoUYlTv8VydFy68kiK6jQDv4hgRXhnwM4OHU=; b=mbIy2DLZlXSicA33ZCuN2AetVqtaFS0yjVF8HWjHrRfl+2MBLjOwijSQR/1AJjjh2N KCLUJ22G0Mivp7vLsSpb+0imwhpZKTM5IPbmXav7H9NGwC3oIr96gX4a50NVbWKJZujQ Le4ltnNBBcon+J8BI4FbSd/ggUSDACLzYYet7029f75iFEJ0i0GU654hhQzNrP5dTuWl +UdkbfsqaB4XCDKka1E7+CGOC3eOJZh5hlKLHCcFr8xTmKp2eFv0poH6eTCEe6eE8ItQ ZK/22hw7rXXp5hme96HZdpIIUTWJs0zblJoJJ1RK3QuLCMAmahSlzk95z8E/f5m8XVZ3 IuOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hpTpsNnGoUYlTv8VydFy68kiK6jQDv4hgRXhnwM4OHU=; b=ibUHxli7wz+7IIIhu2c1Y+2XnYP1K7BwBauyPbTzMWyd2vrgEqPOWa1/mas2+gb7XH OQ/cHsGnyFx4rXxemMnMl+6nEawx4THYtA254avwncXgBvq9ulDyNYstnFjYayPPC2p7 eanIRBy6ZaCLMyfloo31Y+j336YMuI6/yD7D6QcEGJdSvsqMgRu4ikSxnd1V0qiZ5nLk nahztfNNZWG8dbQ0cWI5JrfGAR/CtLmTDa9tIO0mqHE1mGnq6BXOTmHzHZoz6gDwGF45 2jwXHUPTvh2jtqgAhC2TmWMBEEHNaT9oBK7w6BgTEGd/uWEPb0ssR/Iz2w+tAwStCkxk GXaQ== X-Gm-Message-State: AOUpUlEqvc/N6qxWUgAr7s6+rPGz8WNrl/TD/E11ffK7Hv6tFtVzN49g qzIhSTjXYx53oQwADkL106BEA1YVMpNfFaungtw= X-Received: by 2002:a9f:2187:: with SMTP id 7-v6mr8440701uac.49.1533478156301; Sun, 05 Aug 2018 07:09:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a67:2149:0:0:0:0:0 with HTTP; Sun, 5 Aug 2018 07:09:15 -0700 (PDT) In-Reply-To: References: From: Andy Shevchenko Date: Sun, 5 Aug 2018 17:09:15 +0300 Message-ID: Subject: Re: [PATCH] eeprom: at24: Fix unexpected timeout under high load To: "Jonas Mark (BT-FIR/ENG1)" Cc: Bartosz Golaszewski , Arnd Bergmann , Greg Kroah-Hartman , linux-i2c , Linux Kernel Mailing List , "WANG Xin (BT-FIR/ENG1-Zhu)" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Aug 5, 2018 at 3:26 PM, Jonas Mark (BT-FIR/ENG1) wrote: > Hi Andy, > > Thank you for your feedback. > >> > -#define at24_loop_until_timeout(tout, op_time) \ >> > - for (tout = jiffies + msecs_to_jiffies(at24_write_timeout), \ >> > - op_time = 0; \ >> > - op_time ? time_before(op_time, tout) : true; \ >> > - usleep_range(1000, 1500), op_time = jiffies) >> >> This one understandble and represents one operation. > > It just has the downside that it will not retry if the timeout is > reached after the usleep_range(). > > If you have a system which combines high CPU load with repeated EEPROM > writes you will run into the following scenario: > > - System makes a successful regmap_bulk_write() to EEPROM. > - System wants to perform another write to EEPROM but EEPROM is still > busy with the last write. > - Because of high CPU load the usleep_range() will sleep more than > 25 ms (at24_write_timeout). > - Within the over-long sleeping the EEPROM finished the previous write > operation and is ready again. > - at24_loop_until_timeout() will detect timeout and won't try to write. > > The scenario above happens very often on our system and we need a fix. Thanks for explanation why. (it would be good partially move this to the commit message). > >> > +#define at24_loop_until_timeout_begin(tout, op_time) \ >> > + tout = jiffies + msecs_to_jiffies(at24_write_timeout); \ >> > + while (true) { \ >> > + op_time = jiffies; >> > + >> > +#define at24_loop_until_timeout_end(tout, op_time) \ >> > + if (time_before(tout, op_time)) \ >> > + break; \ >> > + usleep_range(1000, 1500); \ >> > + } >> >> Besides `while (true)`, which is a red flag for timeout loops, >> these are done in an hack way. Just open code them in both cases, or >> rewrite original one to keel it's semantics. > > I have to admit that I am not sure what you mean. > > We kept the macro-style of the loop because we assumed it was good > style in this context. No way. It's a bad style when you have a macro like you proposing. It would give you a bottle of sparkling bugs. > What does "keel it's semantics" mean? Macro should be standalone piece of code which does something from A to Z, not from A-K when you need a complementary macro to do L-Z parts. > With "open code them in both cases" do you mean to rid of the macro > and to directly write the loop into the code? Does the following > match your proposals? > > ret = 0; > tout = jiffies + msecs_to_jiffies(at24_write_timeout); > do { > if (ret) > usleep_range(1000, 1500); > > read_time = jiffies; > > ret = regmap_bulk_read(regmap, offset, buf, count); > dev_dbg(&client->dev, "read %zu@%d --> %d (%ld)\n", > count, offset, ret, jiffies); > if (!ret) > return count; > } while (!time_before(tout, read_time)) Yes, though, please, look at the examples in the existing code and make it slightly better timeout = ... do { ret = ... if (ret) // or if (!ret) ... usleep_range(...); } while(time_before(...)); -- With Best Regards, Andy Shevchenko