Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp440651pxb; Fri, 16 Apr 2021 09:13:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwV9I6NlQGrRsF+FewJoBwPxR1Y3kf03pL0phvFJLGxCSoJ6PuiUGpjz7VtVTGEwl/vfXJN X-Received: by 2002:a17:906:6d41:: with SMTP id a1mr1772524ejt.482.1618589598109; Fri, 16 Apr 2021 09:13:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618589598; cv=none; d=google.com; s=arc-20160816; b=fA/6I4KSjb4YPzHW7DGWwBuBO/k6hr8aTsE1Q73kgv9GwzW6YtQ7ybrHlgilVTRSih jzEQGabxTpzQQMwp50vu/fT8C9UTh49hfzb6Qnchu5KghGpfsVfYNIVMgdg5HOlPvCXb /FqKpgcNWG+0qKfZH2+sTyzwkZsGSbCmjZTvUQkWT+XpLBCbFUKBVwT7QZBycsrfiMI6 QPVEhwbMsYFnl7aBCYNSfL8GziHhmbz1ZPudQyH/N9BMGbg4Jb6uYwkHV11Ssv/W35FK Q00KhKJ5DxwYbBkeI5julXTzsFu6MLw+1cwIZb9z28SqGoXGAaFkX2gSTraahDomU0WA Aprg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=dBQTxUFrjwvsCdlEVTG7RhY8i8OidyFaeos2pX2WolE=; b=cFFzUv+ftlluh5XOEwH8Rh+fGzUEEMRJh5YFCCafSydmf+jOjDXNMXzr4WrjLKW37y vIM0x9cp/lUA3ytwGzr9s8gk/yx2yDtzwU/szZkWMFc1PqwzRwb5qVwyJGPAnZ3D1501 s3k3RtQVYCM5U0XVSeFzUXTWyX3oMsnx/5JBFFNItm3ooBLWAHp4NX1+t81EfTe/K4DM TXyUSet+xrBLqwOvrhZzDpZDtBk7+5j2cPZAL8Dln5HNlZokJn4oIGiE4HGiD0xPoZ15 +KjZfZCj/Em9xtJSAzNQmggMza37R8IP3hymmxQWso3cKKHEwhfxB1P/jt9AY+Zcwyv8 NbPQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 5si5410868edv.30.2021.04.16.09.12.55; Fri, 16 Apr 2021 09:13:18 -0700 (PDT) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343554AbhDPP27 (ORCPT + 99 others); Fri, 16 Apr 2021 11:28:59 -0400 Received: from mail-pj1-f44.google.com ([209.85.216.44]:45031 "EHLO mail-pj1-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236062AbhDPP24 (ORCPT ); Fri, 16 Apr 2021 11:28:56 -0400 Received: by mail-pj1-f44.google.com with SMTP id q14-20020a17090a430eb02901503aaee02bso3753107pjg.3; Fri, 16 Apr 2021 08:28:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dBQTxUFrjwvsCdlEVTG7RhY8i8OidyFaeos2pX2WolE=; b=GGxeqd8wJlbcVu+Y4DR8TF58GI7SS7GcUPZUFwT+VIsXp54UCnqQiR0YpqFeDuCbG+ Ku9Z9wcMBHIBCMCCiOOEgicdVoi60HCWbBx00+QwHJ0W/Ra0ZfJW2+OhLD8RunbLEwSx gIv575GIOCPB0/6SzAti/sn0EDhVaYE1b23MvVStN9TFNgBZA+86piHrzns1JzLuv+H9 c/J7C3k9jnzNn45Dr5FacORBAlhLhWZECMq4d8s7iWbPu9CG08KKR40msv3hwvnon0L9 p/dQtecfaErO0g0X2GN9Fj+udIM5rSWGheTvLRZGONeLVAXOkBQy+tyecgO3u2QuKM6y FKcA== X-Gm-Message-State: AOAM532Bpq9CR/azO9EyBdl+L/RcUCOdoBwLs7d3nHEF67ROZfWqXxUA YSkqtGuxsZBVrAFuyJYLLuQ= X-Received: by 2002:a17:90b:1e0b:: with SMTP id pg11mr10600410pjb.146.1618586910490; Fri, 16 Apr 2021 08:28:30 -0700 (PDT) Received: from ?IPv6:2601:647:4000:d7:deb4:c899:3eb6:a154? ([2601:647:4000:d7:deb4:c899:3eb6:a154]) by smtp.gmail.com with ESMTPSA id t17sm5285487pfe.35.2021.04.16.08.28.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Apr 2021 08:28:29 -0700 (PDT) Subject: Re: [PATCH v7 1/3] bio: limit bio max size To: Changheun Lee Cc: Johannes.Thumshirn@wdc.com, asml.silence@gmail.com, axboe@kernel.dk, damien.lemoal@wdc.com, gregkh@linuxfoundation.org, hch@infradead.org, jisoo2146.oh@samsung.com, junho89.kim@samsung.com, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, ming.lei@redhat.com, mj0123.lee@samsung.com, osandov@fb.com, patchwork-bot@kernel.org, seunghwan.hyun@samsung.com, sookwan7.kim@samsung.com, tj@kernel.org, tom.leiming@gmail.com, woosung2.lee@samsung.com, yt0928.kim@samsung.com References: <20210416055039.20126-1-nanich.lee@samsung.com> From: Bart Van Assche Message-ID: <9ad8ef3f-905c-543e-d2af-7bf2f43ea04c@acm.org> Date: Fri, 16 Apr 2021 08:28:27 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <20210416055039.20126-1-nanich.lee@samsung.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/15/21 10:50 PM, Changheun Lee wrote: >> On 4/15/21 3:38 AM, Changheun Lee wrote: >>> @@ -538,6 +540,8 @@ int blk_stack_limits(struct queue_limits *t, struct queue_limits *b, >>> { >>> unsigned int top, bottom, alignment, ret = 0; >>> >>> + t->bio_max_bytes = min_not_zero(t->bio_max_bytes, b->bio_max_bytes); >>> + >>> t->max_sectors = min_not_zero(t->max_sectors, b->max_sectors); >>> t->max_hw_sectors = min_not_zero(t->max_hw_sectors, b->max_hw_sectors); >>> t->max_dev_sectors = min_not_zero(t->max_dev_sectors, b->max_dev_sectors); >> >> The above will limit bio_max_bytes for all stacked block devices, which >> is something we do not want. I propose to set t->bio_max_bytes to >> UINT_MAX in blk_stack_limits() and to let the stacked driver (e.g. >> dm-crypt) decide whether or not to lower that value. > > Actually, bio size should be limited in dm-crypt too. Because almost I/O > from user space will be gone to dm-crypt first. I/O issue timing will be > delayed if bio size is not limited in dm-crypt. > Do you have any idea to decide whether takes lower bio max size, or not > in the stacked driver? > Add a flag to decide this in driver layer like before? > Or insert code manually in each stacked driver if it is needed? There will be fewer stacked drivers for which the bio size has to be limited than for which the bio size has not to be limited. Hence the proposal to set t->bio_max_bytes to UINT_MAX in blk_stack_limits() and to let the stacked driver (e.g. dm-crypt) decide whether or not to lower that value. Thanks, Bart.