From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 93E225D8F0; Tue, 17 Sep 2024 06:20:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.95.11.211 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1726554014; cv=none; b=g6m2AXPyuskgyBO0tzQi+ABt/mDG8m04IeKKipgXujERGjUVOonL9x70Wu+nqstOxFVesp51nxqT3B48Z/Kp2utz58XUhCnKWFqGBvBdumneNPwgFSidzu+i4BHe68INFtl5PAF9JbDLPtPWYmLEpr3F060TfR4OqUKy+ZlnkIg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1726554014; c=relaxed/simple; bh=pFzT2ZqtUjl23iIZuzObb5iVFXkufhUazQnZ99FVJjU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=R2yXDxU0UhCo5c+q0MCA8lZ+uw2XQwn4Gw1wvfYG7ISLMUrzA+/VyleIVJQak1Ojzg6exyrl4naEOGOuo+LlNYdEXivjhvwgaGcStjsTiEEIZE3x0pygsNJZuVUJvYvidnHigtS/TyMgqC7b+SyZQ8e294bwnWF1GN8Pq9tkLss= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de; spf=pass smtp.mailfrom=lst.de; arc=none smtp.client-ip=213.95.11.211 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lst.de Received: by verein.lst.de (Postfix, from userid 2407) id C391B227ACB; Tue, 17 Sep 2024 08:20:07 +0200 (CEST) Date: Tue, 17 Sep 2024 08:20:07 +0200 From: Christoph Hellwig To: Kanchan Joshi Cc: Christoph Hellwig , axboe@kernel.dk, kbusch@kernel.org, sagi@grimberg.me, martin.petersen@oracle.com, James.Bottomley@HansenPartnership.com, brauner@kernel.org, viro@zeniv.linux.org.uk, jack@suse.cz, jaegeuk@kernel.org, jlayton@kernel.org, chuck.lever@oracle.com, bvanassche@acm.org, linux-nvme@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-block@vger.kernel.org, linux-scsi@vger.kernel.org, gost.dev@samsung.com, vishak.g@samsung.com, javier.gonz@samsung.com, Nitesh Shetty Subject: Re: [PATCH v5 4/5] sd: limit to use write life hints Message-ID: <20240917062007.GA4170@lst.de> References: <20240910150200.6589-1-joshi.k@samsung.com> <20240910150200.6589-5-joshi.k@samsung.com> <20240912130235.GB28535@lst.de> <20240913080659.GA30525@lst.de> <4a39215a-1b0e-3832-93bd-61e422705f8b@samsung.com> Precedence: bulk X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4a39215a-1b0e-3832-93bd-61e422705f8b@samsung.com> User-Agent: Mutt/1.5.17 (2007-11-01) On Mon, Sep 16, 2024 at 07:19:21PM +0530, Kanchan Joshi wrote: > > Maybe part of the problem is that the API is very confusing. A smal > > part of that is of course that the existing temperature hints already > > have some issues, but this seems to be taking them make it significantly > > worse. > > Can you explain what part is confusing. This is a simple API that takes > type/value pair. Two types (and respective values) are clearly defined > currently, and more can be added in future. I though I outlined that below. > > But if we increase this to a variable number of hints that don't have > > any meaning (and even if that is just the rough order of the temperature > > hints assigned to them), that doesn't really work. We'll need an API > > to check if these stream hints are supported and how many of them, > > otherwise the applications can't make any sensible use of them. > > - Since writes are backward compatible, nothing bad happens if the > passed placement-hint value is not supported. Maybe desired outcome (in > terms of WAF reduction) may not come but that's not a kernel problem > anyway. It's rather about how well application is segregating and how > well device is doing its job. What do you mean with "writes are backward compatible" ? > - Device is perfectly happy to work with numbers (0 to 256 in current > spec) to produce some value (i.e., WAF reduction). Any extra > semantics/abstraction on these numbers only adds to the work without > increasing that value. If any application needs that, it's free to > attach any meaning/semantics to these numbers. If the device (or file system, which really needs to be in control for actual files vs just block devices) does not support all 256 we need to reduce them to less than that. The kernel can help with that a bit if the streams have meanings (collapsing temperature levels that are close), but not at all if they don't have meanings. The application can and thus needs to know the number of separate streams available. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1783EC3ABDB for ; Tue, 17 Sep 2024 06:20:29 +0000 (UTC) Received: from [127.0.0.1] (helo=sfs-ml-4.v29.lw.sourceforge.com) by sfs-ml-4.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1sqRZZ-00069s-9R; Tue, 17 Sep 2024 06:20:25 +0000 Received: from [172.30.29.66] (helo=mx.sourceforge.net) by sfs-ml-4.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1sqRZX-00069k-73 for linux-f2fs-devel@lists.sourceforge.net; Tue, 17 Sep 2024 06:20:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=e/0YPUvuaLiWEAkJzh1AOKZrqRluEA0zzP4hr9kHNrg=; b=K2ACSkPM6a7yUnFLlM38EuGhKi xcMlAI3imtJN7lvMrEZ5lCOqrTGQl4hOdW+l4Pn4VsrGNaaJUUrZjHg6hFSHRGmu2/bCT0MgCPtmX csH8bTlJIz7cM4oNh3/eX2vYhIj0cBa+Xq/9pZHe39IxjrskBA97IIjrGEg6puc6jyX8=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=e/0YPUvuaLiWEAkJzh1AOKZrqRluEA0zzP4hr9kHNrg=; b=QgMbNpsnBr0umeNBzIzf6jESBF 5d+Zgfp8hV91oa2X4X8kFL9EP5Bn6NJzni4t6Gn5K+aOUF0rYuH9lfdVjJpaKobsIHnPn2NribZ/K htG2DAfSXvaGIPSELV8QMQAhx56t8QWgIyirq4E8qXc7vGNVjjLInSLa95BG39upBoSU=; Received: from verein.lst.de ([213.95.11.211]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1sqRZW-00067W-3W for linux-f2fs-devel@lists.sourceforge.net; Tue, 17 Sep 2024 06:20:23 +0000 Received: by verein.lst.de (Postfix, from userid 2407) id C391B227ACB; Tue, 17 Sep 2024 08:20:07 +0200 (CEST) Date: Tue, 17 Sep 2024 08:20:07 +0200 From: Christoph Hellwig To: Kanchan Joshi Message-ID: <20240917062007.GA4170@lst.de> References: <20240910150200.6589-1-joshi.k@samsung.com> <20240910150200.6589-5-joshi.k@samsung.com> <20240912130235.GB28535@lst.de> <20240913080659.GA30525@lst.de> <4a39215a-1b0e-3832-93bd-61e422705f8b@samsung.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4a39215a-1b0e-3832-93bd-61e422705f8b@samsung.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Headers-End: 1sqRZW-00067W-3W Subject: Re: [f2fs-dev] [PATCH v5 4/5] sd: limit to use write life hints X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: vishak.g@samsung.com, jack@suse.cz, linux-nvme@lists.infradead.org, James.Bottomley@HansenPartnership.com, Christoph Hellwig , sagi@grimberg.me, linux-scsi@vger.kernel.org, gost.dev@samsung.com, Nitesh Shetty , linux-block@vger.kernel.org, viro@zeniv.linux.org.uk, kbusch@kernel.org, jaegeuk@kernel.org, bvanassche@acm.org, axboe@kernel.dk, brauner@kernel.org, martin.petersen@oracle.com, jlayton@kernel.org, linux-f2fs-devel@lists.sourceforge.net, chuck.lever@oracle.com, linux-fsdevel@vger.kernel.org, javier.gonz@samsung.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On Mon, Sep 16, 2024 at 07:19:21PM +0530, Kanchan Joshi wrote: > > Maybe part of the problem is that the API is very confusing. A smal > > part of that is of course that the existing temperature hints already > > have some issues, but this seems to be taking them make it significantly > > worse. > > Can you explain what part is confusing. This is a simple API that takes > type/value pair. Two types (and respective values) are clearly defined > currently, and more can be added in future. I though I outlined that below. > > But if we increase this to a variable number of hints that don't have > > any meaning (and even if that is just the rough order of the temperature > > hints assigned to them), that doesn't really work. We'll need an API > > to check if these stream hints are supported and how many of them, > > otherwise the applications can't make any sensible use of them. > > - Since writes are backward compatible, nothing bad happens if the > passed placement-hint value is not supported. Maybe desired outcome (in > terms of WAF reduction) may not come but that's not a kernel problem > anyway. It's rather about how well application is segregating and how > well device is doing its job. What do you mean with "writes are backward compatible" ? > - Device is perfectly happy to work with numbers (0 to 256 in current > spec) to produce some value (i.e., WAF reduction). Any extra > semantics/abstraction on these numbers only adds to the work without > increasing that value. If any application needs that, it's free to > attach any meaning/semantics to these numbers. If the device (or file system, which really needs to be in control for actual files vs just block devices) does not support all 256 we need to reduce them to less than that. The kernel can help with that a bit if the streams have meanings (collapsing temperature levels that are close), but not at all if they don't have meanings. The application can and thus needs to know the number of separate streams available. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel