From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751284AbdH2HTO (ORCPT ); Tue, 29 Aug 2017 03:19:14 -0400 Received: from mga14.intel.com ([192.55.52.115]:44450 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751180AbdH2HTN (ORCPT ); Tue, 29 Aug 2017 03:19:13 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,444,1498546800"; d="scan'208";a="1189236387" Subject: Re: [Intel-wired-lan] [PATCH] e1000e: changed some expensive calls of udelay to usleep_range To: Matthew Tan , jeffrey.t.kirsher@intel.com References: <1503503985-3869-1-git-send-email-matthew.tan_1@nxp.com> Cc: michael.kardonik@nxp.com, mitch.a.williams@intel.com, linux-kernel@vger.kernel.org, john.ronciak@intel.com, intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org From: "Neftin, Sasha" Message-ID: Date: Tue, 29 Aug 2017 10:19:09 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <1503503985-3869-1-git-send-email-matthew.tan_1@nxp.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/23/2017 18:59, Matthew Tan wrote: > Calls to udelay are not preemtable by userspace so userspace > applications experience a large (~200us) latency when running on core > 0. Instead usleep_range can be used to be more friendly to userspace > since it is preemtable. This is due to udelay using busy-wait loops > while usleep_rang uses hrtimers instead. It is recommended to use > udelay when the delay is <10us since at that precision overhead of > usleep_range hrtimer setup causes issues. However, the replaced calls > are for 50us and 100us so this should not be not an issue. > > Signed-off-by: Matthew Tan > --- > drivers/net/ethernet/intel/e1000e/phy.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/net/ethernet/intel/e1000e/phy.c b/drivers/net/ethernet/intel/e1000e/phy.c > index de13aea..e318fdc 100644 > --- a/drivers/net/ethernet/intel/e1000e/phy.c > +++ b/drivers/net/ethernet/intel/e1000e/phy.c > @@ -158,7 +158,7 @@ s32 e1000e_read_phy_reg_mdic(struct e1000_hw *hw, u32 offset, u16 *data) > * the lower time out > */ > for (i = 0; i < (E1000_GEN_POLL_TIMEOUT * 3); i++) { > - udelay(50); > + usleep_range(40, 60); > mdic = er32(MDIC); > if (mdic & E1000_MDIC_READY) > break; > @@ -183,7 +183,7 @@ s32 e1000e_read_phy_reg_mdic(struct e1000_hw *hw, u32 offset, u16 *data) > * reading duplicate data in the next MDIC transaction. > */ > if (hw->mac.type == e1000_pch2lan) > - udelay(100); > + usleep_range(90, 100); > > return 0; > } > @@ -222,7 +222,7 @@ s32 e1000e_write_phy_reg_mdic(struct e1000_hw *hw, u32 offset, u16 data) > * the lower time out > */ > for (i = 0; i < (E1000_GEN_POLL_TIMEOUT * 3); i++) { > - udelay(50); > + usleep_range(40, 60); > mdic = er32(MDIC); > if (mdic & E1000_MDIC_READY) > break; > @@ -246,7 +246,7 @@ s32 e1000e_write_phy_reg_mdic(struct e1000_hw *hw, u32 offset, u16 data) > * reading duplicate data in the next MDIC transaction. > */ > if (hw->mac.type == e1000_pch2lan) > - udelay(100); > + usleep_range(90, 110); > > return 0; > } Reasonable. Do you have any open bug or other reference describe this problem?