Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2312474ybz; Thu, 30 Apr 2020 14:57:26 -0700 (PDT) X-Google-Smtp-Source: APiQypJ+5KlsjVfHLHQyWTsw593Le5Wia6Nx66oh4yna2C1JfuiyYTqHThVYdYNNFLFegWk2Wngr X-Received: by 2002:a50:9e2a:: with SMTP id z39mr1015169ede.371.1588283845910; Thu, 30 Apr 2020 14:57:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588283845; cv=none; d=google.com; s=arc-20160816; b=QBn3XXbRK7HNQYkYZnHjEmzhmRgokDzNHUDjl5wyo84eOeCv0SrI5k2ph/Al52cc9a hu6xPySn+nfmhZnyUwMBxe8Nys65/UkHvYp7QR/hrSTBLd/6KoZqYOckO3Bv/fB/zeJ/ jL61PxEDJxbItn3bGh1IfHF7i6yhukw+3o67AxOTvczi6hGnmDIwjSVUTsOwTsvZaDod +I6pmpg0sxDmPBzDTgorgOrDs8FjslG6KIz9kF6HO0uLmbWmSn22rPkskXLnkl68Vldc k0rU/KYjSLofizJH/TdN/l0YTsG4pf33amVTMyvAis3GLf0ZdvcuTrtQ0r6aUBoj8XLQ Tf/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=rYEprxh5hRkyIRk0SZJ1yYwJF2zaPFW1K1pdxuC7Zuc=; b=raePwLvDbhmuR79sSYqHaMaOdMV1/7Xd1x+mnKHmzuudxK7MDqrvQTSev+RLFalVJM LchyWF/O6Wsd+VYXuP4HEVwZ9sS/vBRggF2SDoQ5HY97llDHBRCNsIdktbndymG4l7H7 xO5vQITUxyAn8RlUPO0WuoX3RsJXSWvRWKDyrAp/YbO77j9SBAe2DUX+UwalL7/tt53D RWB2/+/61kDSRRK2sSLE+apDaO6wo2N6k0czgqLD1Ylc6ea/pmdnKYiWlBfdtMhg5vrM MslschLSZCzSGbTZAiYmz9Nz9iSDBnE1l9o2EVWVSXGLlUmpcmiIWS7lvx4/UrV1hrQo Tlpw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=0YJweBxd; 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 g8si600412edn.504.2020.04.30.14.56.55; Thu, 30 Apr 2020 14:57:25 -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; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=0YJweBxd; 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 S1727890AbgD3Vzd (ORCPT + 99 others); Thu, 30 Apr 2020 17:55:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46460 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726817AbgD3Vzd (ORCPT ); Thu, 30 Apr 2020 17:55:33 -0400 Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 096C3C035495 for ; Thu, 30 Apr 2020 14:55:33 -0700 (PDT) Received: by mail-pl1-x643.google.com with SMTP id v2so2847996plp.9 for ; Thu, 30 Apr 2020 14:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=rYEprxh5hRkyIRk0SZJ1yYwJF2zaPFW1K1pdxuC7Zuc=; b=0YJweBxdqRGXk8CKADPYZT2TDMDjlejyhecZFIP6Pdqu2Rol0vua+RkjawOc6lW+4C uye8FqmbkqGQFahJuYyZ/sVkYDn8YKcognO7HZN5LGsmML6yIXlmeCxIkANnyZNQ1gTG /9xSR/dOm1broZSmXWyPapxeqpe3M9DwJQedEjQkHUFGZC4OxPB9a94qfaCo8FkfLTG2 z4UdgSMg6xqZqbdaMkkKFbSj8MCsvkht1TJbHhLVLcwEjDr92euBMUJXifl8yCQybF3i 0VWB+PK6QrXPrkeZTzbIW4Ds0P1gdgZDHzx3P27ENgTnRXQIqNtK/jjJtTG7opYmGATG kgeg== 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=rYEprxh5hRkyIRk0SZJ1yYwJF2zaPFW1K1pdxuC7Zuc=; b=fHRPwt4ZW/lhKMJ0cPPY40CI0qEtK31hy6HpvewNt3ey8tn5EsBzPbs/UzEClHqZH1 3f2NjIotUWFuojABxiwyK4LvGjnbFfNv8mrk4KZ82gljz1809zCDzQJXOJQKAeCyzEBi ydcRAoBP2KshS49G8+1jROAj2InD5tEddLEAtiAjsLAAbPazk4wywrE/JPhOTEo4WnYq 3Bb+0NXr3K8FueCfLLZBWfeWni7ExY8GkkAKG6/h0zX4nGFEPhx0Jv8BKm1+8PwvoaeB Os3vebM29cA5S/T7fzFTP0iocqXb8EboY8AhKDISzPfynLets0tDh/2Igx3E1xRXtkeo z5kw== X-Gm-Message-State: AGi0PuZeDNd+5TtSF2DGwD3Q+aG8kRXLH6DsiPb6pXRfd03pC+6ohnMV ghI/NMJreePsWt9JlprqmOjqRA== X-Received: by 2002:a17:902:7b94:: with SMTP id w20mr1140125pll.8.1588283732465; Thu, 30 Apr 2020 14:55:32 -0700 (PDT) Received: from [192.168.1.188] ([66.219.217.145]) by smtp.gmail.com with ESMTPSA id i25sm601473pfo.196.2020.04.30.14.55.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Apr 2020 14:55:31 -0700 (PDT) Subject: Re: [PATCHSET v2 block/for-5.8] iocost: improve use_delay and latency target handling To: Tejun Heo Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, cgroups@vger.kernel.org, newella@fb.com, josef@toxicpanda.com, asml.silence@gmail.com, ming.lei@redhat.com, bvanassche@acm.org References: <20200413162758.97252-1-tj@kernel.org> From: Jens Axboe Message-ID: <6ee6360e-1a35-874c-2263-6fb21da66591@kernel.dk> Date: Thu, 30 Apr 2020 15:55:30 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200413162758.97252-1-tj@kernel.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/13/20 10:27 AM, Tejun Heo wrote: > Changes from v1[1] > > * Dropped 0002-block-add-request-io_data_len.patch and updated to use > rq->stats_sectors instead as suggested by Pavel Begunkov. > > This patchset improves the following two iocost control behaviors. > > * iocost was failing to punish heavy shared IO generators (file metadata, memory > reclaim) through use_delay mechanism - use_delay automatically decays which > works well for iolatency but doesn't match how iocost behaves. This led to > e.g. memory bombs which generate a lot of swap IOs to use over their allotted > amount. This is fixed by adding non-decaying use_delay mechanism. > > * The same latency targets were being applied regardless of the IO sizes. While > this works fine for loose targets, it gets in the way when trying to tigthen > them - a latency target adequate for a 4k IO is too short for a 1 meg IO. > iocost now discounts the size portion of cost when testing whether a given IO > met or missed its latency target. > > While at it, it also makes minor changse to iocost_monitor.py. > > This patchset contains the following five patches. > > 0001-blk-iocost-switch-to-fixed-non-auto-decaying-use_del.patch > 0002-blk-iocost-account-for-IO-size-when-testing-latencie.patch > 0003-iocost_monitor-exit-successfully-if-interval-is-zero.patch > 0004-iocost_monitor-drop-string-wrap-around-numbers-when-.patch > > and is also available in the following git branch. > > git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git iocost-delay-latency-v2 > > diffstat follows. Thanks. > > block/Kconfig | 1 > block/blk-cgroup.c | 6 ++++ > block/blk-iocost.c | 56 +++++++++++++++++++++++++++++------------ > include/linux/blk-cgroup.h | 43 ++++++++++++++++++++++++------- > tools/cgroup/iocost_monitor.py | 48 +++++++++++++++++++---------------- > 5 files changed, 106 insertions(+), 48 deletions(-) Applied, thanks Tejun. -- Jens Axboe