Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1116617yba; Tue, 2 Apr 2019 02:38:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqwyu8UADJEBkMn0NMitWH80sPYa9n3LCiD96P3K42n+JbubzFqfyZcvGO5ZhqhKivLbvVNT X-Received: by 2002:a62:388d:: with SMTP id f135mr53610225pfa.103.1554197898409; Tue, 02 Apr 2019 02:38:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554197898; cv=none; d=google.com; s=arc-20160816; b=RCQ5ciuvztBae4f3KxA6TIXMMUGX6C0jsYPb4qujxLUibm3TOlPwrtLPPR76mW2zjs 855qR5kNXDZxSPQhC+m/4UOoY1KztVgJ2EjBc0b5EXXt3nrlCtjKYYTx/9a8hDX+NZPs pIFayXlyQqKY57JhIJSN5msunJ92V/2e/mg0FA53D5+WCyvPTb+Vyiuv26bd8lp0r9PD eWNEcYy2KHbYsb7Q611SefNEM0Bz4KHv8njPnRSmWX+Vb6mfYSIAvkFbpj1/biFgFqEe yeYRq04qmsSmbw0Y+DSdwCuIrsV2NihYhMWcOm5BXdTVQivDGqg1uOiXpu9F/ePJ5R8P mWHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=bR3gghIewGJFkDr4xq16AM+3gG9Pf38Y0oqOV5HqpLU=; b=XX5n1IQcMoTtkIIsRrvqzcmr9srnet5EU0PpRXYXonZO5SXzMRfC1jd3zqWyUU9qa+ hyINiLi54aWIIzCkGNd3NqbVuqGwfBbhUwzrzHghqXebnha8aksF4zbgaqRC7Bxo4KZ0 zWcBxyUtjQwoKHLaRjOlNwthudukTtbvBDDPT/rZALJsrwxOBtDGF7bkhNPZMlTIqcgU c/2uEyfJ1eqSjyu5Nu8ltX1zB+alGl4666No4K+NvPKUucvMh+dQU7UdU8Xek4UskuYr MhTJeRYOuXXFS+HpHD9cJqLRXFNHX5KFLgnpQBoVMiL4Yv1ryRazytj3pcoh+nhj6YmQ CCwA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 195si10538519pgc.279.2019.04.02.02.38.02; Tue, 02 Apr 2019 02:38:18 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729993AbfDBJUr (ORCPT + 99 others); Tue, 2 Apr 2019 05:20:47 -0400 Received: from mx2.suse.de ([195.135.220.15]:47816 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728684AbfDBJUr (ORCPT ); Tue, 2 Apr 2019 05:20:47 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id C1DBDAB48; Tue, 2 Apr 2019 09:20:45 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id DF8721E42C7; Tue, 2 Apr 2019 11:20:44 +0200 (CEST) Date: Tue, 2 Apr 2019 11:20:44 +0200 From: Jan Kara To: Dave Chinner Cc: Kanchan Joshi , linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-nvme@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, axboe@fb.com, prakash.v@samsung.com, anshul@samsung.com, joshiiitr@gmail.com Subject: Re: [PATCH v3 3/7] block: add write-hint to stream-id conversion Message-ID: <20190402092044.GE12133@quack2.suse.cz> References: <1553846032-4451-1-git-send-email-joshi.k@samsung.com> <1553846032-4451-4-git-send-email-joshi.k@samsung.com> <20190401050821.GQ23020@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190401050821.GQ23020@dastard> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 01-04-19 16:08:21, Dave Chinner wrote: > On Fri, Mar 29, 2019 at 01:23:48PM +0530, Kanchan Joshi wrote: > > + if(streamid > nr_streams) > > + streamid = 0; > > So, basically, we'll compress all the kernel hints down to "no hint" > if there are more user streams than the device supports? > > Surely we should be reserving a stream for the kernel hints separate > from the user and "none" streams when we have limited device streams > available... The question is what to do in a situation when the device has exactly as many hints as we currently offer to userspace. Because currently either the device has enough hints for all userspace hint values or we disable the feature altogether. If we always mandated some hints are available for the kernel, we'd have to regress some fuctionality currently available to userspace. So I think that the option that the kernel won't get any hints is the least painful solution. Later when people would like to extend hints available to userspace, we could make sure kernel's batch of hints has priority over these "extended userspace hints". Honza -- Jan Kara SUSE Labs, CR