Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp211580pxb; Tue, 2 Feb 2021 03:19:05 -0800 (PST) X-Google-Smtp-Source: ABdhPJxkldp5wmW+AZr/8I9EobOyUodb07C1+pgNhhxf6MeEfKqLMAmEnkRAknF5RLJFD43ZP6KT X-Received: by 2002:a17:907:a059:: with SMTP id gz25mr9776068ejc.400.1612264745489; Tue, 02 Feb 2021 03:19:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612264745; cv=none; d=google.com; s=arc-20160816; b=QhfC8aYy0TAEvuBz/AUwlLyvyLy9WB1l5lcGXIJKrgrncD+QPGS6OxJ4nJbtMOl6PD bfgRi3iPmUez2w2n1oRJW38okDs6/5T8rbBS4MyIAZrBrLElvqSp0hNc72zeqyg9N99Y BGxYmnb2SUB32UweGJujWVYTYJ45din1u/DHB+c4pksE3kJT8F7a2aY4FBsWH55GlLPh J3WP2idVj4LVPzvoVu+QyAVzB8yaNfOLdQ31Uo+CMboLkiH52Ew/8yg7cs1lSsUvNWyR LqEtlh+U4pkY+5yd6vE4V7WNfYIZAIIoSkdFz6/e9n6Do3iB2gQDrTpYFvlTVlKtcoM/ Sivw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=bQ0+atS8vya2Q2WFvRSJFLluuSQzB/DpCPIxfEeRzto=; b=Kat2ELnLUuHub2GE/mnKGhsDJGmFJeKPf6py5IJeaLiSwan1bDrOgMNLhyYQVsCpJj dO7ZfDti6w67XTYqs3p7Mr+c0ctX9V2rTxG3PiqvzN/wYeymhKymGMEN+gp0gUSp5cK9 sNV8pYAvro7gjpJ0aJrdq99P1hrXceoBJMhFxaBa++QbadbedD36OWH+E6aiO/Rgf/YM DA6nXuo7FAJwfgXNjvvh7320xqot4Uh+urxHdKLPFHa7iberOFK5gclToIOSvCOrBVCQ 39CRgEYNRPxWjVuK3rBIQj25fGf1gqak2ZP8GPWc7apWXV8/6uiMC/mlWjUjDiZwQy1Y 59Og== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=KEARUBv7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e17si12017374ejr.533.2021.02.02.03.18.36; Tue, 02 Feb 2021 03:19:05 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=KEARUBv7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229724AbhBBLRz (ORCPT + 99 others); Tue, 2 Feb 2021 06:17:55 -0500 Received: from mail.kernel.org ([198.145.29.99]:56754 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229623AbhBBLRx (ORCPT ); Tue, 2 Feb 2021 06:17:53 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id C267064E4C; Tue, 2 Feb 2021 11:17:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1612264632; bh=Gt/tRLSzeC4EBMRqE7w8RU/ECKnbCos15/tnw0of2J8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KEARUBv73fJRZJqbAvj8GNznrlObLkHQMhAKUmNZqUc/suX+Qa4DqCI/U2InILw4S G+wZYDWTx3zEUBvo4RtNKFNMO1R8s2sdqKNOFjzTMgpK5BE3pWbsa8+qLspbQm8HgR vznCfGAistzf+Bn2HMfdX2cOKqSI7uOd85qJDvUs= Date: Tue, 2 Feb 2021 12:17:07 +0100 From: Greg KH To: Avri Altman Cc: "James E . J . Bottomley" , "Martin K . Petersen" , linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, Bart Van Assche , yongmyung lee , Daejun Park , alim.akhtar@samsung.com, asutoshd@codeaurora.org, Zang Leigang , Avi Shchislowski , Bean Huo , cang@codeaurora.org, stanley.chu@mediatek.com Subject: Re: [PATCH v2 9/9] scsi: ufshpb: Make host mode parameters configurable Message-ID: References: <20210202083007.104050-1-avri.altman@wdc.com> <20210202083007.104050-10-avri.altman@wdc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210202083007.104050-10-avri.altman@wdc.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 02, 2021 at 10:30:07AM +0200, Avri Altman wrote: > We can make use of this commit, to elaborate some more of the host > control mode logic, explaining what role play each and every variable: > > - activation_thld - In host control mode, reads are the major source of > activation trials. once this threshold hs met, the region is added > to the "to-be-activated" list. Since we reset the read counter upon > write, this include sending a rb command updating the region ppn as > well. > > - normalization_factor - We think of the regions as "buckets". Those > buckets are being filled with reads, and emptied on write. We use > entries_per_srgn - the amount of blocks in a subregion as our bucket > size. This applies because HPB1.0 only concern a single-block > reads. Once the bucket size is crossed, we trigger a normalization > work - not only to avoid overflow, but mainly because we want to > keep those counters normalized, as we are using those reads as a > comparative score, to make various decisions. The normalization is > dividing (shift right) the read counter by the normalization_factor. > If during consecutive normalizations an active region has exhaust > its reads - inactivate it. > > - eviction_thld_enter - Region deactivation is often due to the fact > that eviction took place: a region become active on the expense of > another. This is happening when the max-active-regions limit has > crossed. In host mode, eviction is considered an extreme measure. > We want to verify that the entering region has enough reads, and the > exiting region has much less reads. eviction_thld_enter is the min > reads that a region must have in order to be considered as a > candidate to evict other region. > > - eviction_thld_exit - same as above for the exiting region. A region > is consider to be a candidate to be evicted, only if it has less > reads than eviction_thld_exit. > > - read_timeout_ms - In order not to hang on to “cold” regions, we > shall inactivate a region that has no READ access for a predefined > amount of time - read_timeout_ms. If read_timeout_ms has expired, > and the region is dirty - it is less likely that we can make any > use of HPB-READing it. So we inactivate it. Still, deactivation > has its overhead, and we may still benefit from HPB-READing this > region if it is clean - see read_timeout_expiries. > > - read_timeout_expiries - if the region read timeout has expired, but > the region is clean, just re-wind its timer for another spin. Do > that as long as it is clean and did not exhaust its > read_timeout_expiries threshold. > > - timeout_polling_interval_ms - the frequency in which the delayed > worker that checks the read_timeouts is awaken. You create new sysfs files, but fail to document them in Documentation/ABI/ which is where the above information needs to go :( thanks, greg k-h