From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-251.mta0.migadu.com [91.218.175.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E5BDA44780D for ; Wed, 16 Sep 2026 08:21:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.251 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789546910; cv=none; b=rab7QDOouYrfe6BG426qg8ccQVlQBPbSU3BVC3q4FpCBOfZygznpw26tPnKBL4EOey+bTIGauJrExfBK0ZJ1LIEOgXzkLRkHF/vdTnnHeFahk3dqCaVYQmfRk8ITggzC6SKGxRaL1bzZndR9Bad5dxmeqcvZMyvwzGUNN6mEvt8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789546910; c=relaxed/simple; bh=4QEPSFxwOL/UNwt7iBdY4dY2kx7+/Hzz8r4iula/V3k=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=J/PJjr4dLUnwvyeOgyDta66agLbjthLO+Fnj698kCz9MbhEGTU/i/glEZRxEQQEliRs02dbD7rBgSOJHKYgaDjBRSVNof4Q2oYKmFvPdMtdLXVDW+UZFo9XBsWqH0/ibf7ONrsPN0nlN/xczMdqwpqM0moP6qLOK3t7TvGBP8ho= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=bwBBKKh3; arc=none smtp.client-ip=91.218.175.251 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="bwBBKKh3" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=4QEPSFxwOL/UNwt7iBdY4dY2kx7+/Hzz8r4iula/V3k=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1789546894; v=1; x=1790151694; b=bwBBKKh3ulVmlTiRnvDIssj406RkbdUEPiWgO3kWpi7/h5u8gER54j04AFHkt1syGy161qXC Vk9SlrVo2px1uN+4JntQL04OmbXZnOlp0M296HP59fM2rkjkzkRqhp8/BUZFdE+2gItu2tujU/O OvFVxD5FsVS0P1fRZYpkju74= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id a6cdd9e4629a66e4; Wed, 16 Sep 2026 08:21:23 +0000 X-Mizu-Trace-ID: a6cdd9e4629a66e4 X-Migadu-Flow: FLOW_OUT Message-ID: Date: Wed, 16 Sep 2026 16:21:20 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: cui.tao@linux.dev, tj@kernel.org, josef@toxicopanda.com, axboe@kernel.dk, cgroups@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, Tao Cui Subject: Re: [PATCH 1/4] blk-iocost: charge flushes as pageless random writes To: Christoph Hellwig References: <20260908022135.1429281-1-cui.tao@linux.dev> <20260908022135.1429281-2-cui.tao@linux.dev> From: Tao Cui In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi, Christoph 在 2026/9/10 13:41, Christoph Hellwig 写道: > On Tue, Sep 08, 2026 at 10:21:32AM +0800, Tao Cui wrote: >> From: Tao Cui >> >> Standalone flushes issued by blkdev_issue_flush() are represented as >> dataless REQ_OP_WRITE | REQ_PREFLUSH bios, which >> calc_vtime_cost_builtin() prices at zero. The flush component of >> flush-heavy workloads such as database commits, journal flushes, and >> metadata sync is thus neither charged nor throttled: a cgroup at 1% weight >> can issue ~510k flushes per 12s, monopolizing the device while iocost >> reports zero usage. >> >> Price them as pageless random writes (LCOEF_WRANDIO), which provides >> an approximation of the device time consumed by a flush. For >> profiles where WRANDIO clamps to zero (ssd_dfl / ssd_fast), use a >> one-page floor (LCOEF_WPAGE). After this patch, the same 1%-weight >> cgroup is limited to 24 flushes per 12s; on ext4, write+fsync >> workloads are correctly accounted through the journal layer (~2.2us >> per flush on the ssd_fast profile). > > Flushes are actually a really interesting case. For devics with > a non-volatile write cache they are no-ops, but submit_bio should > ensure we never see them here. Confirmed. submit_bio_noacct() strips REQ_PREFLUSH and completes dataless flush bios early when !bdev_write_cache(), so they never reach ioc_rqos_throttle(). The charge only applies where the device actually has to drain a cache. > But devices with a volatile write > cache they are significantly more expensive than any kind of write. > If we touch this we should probably figure out a way to model that. > Note that this includes standalone flushes and PREFLUSH ones, > so this patch might be a good start, but still is missing a very > important part. Right. The PREFLUSH component of data-bearing writes is the same class of bug as the standalone flush (uncharged device time), so I'll fold that into v2 as a bugfix: any REQ_PREFLUSH bio gets a flush surcharge on top of its data cost, with the same write-coefficient fallback. For the pricing itself I'm preparing a follow-up RFC with a dedicated flushiops= entry in io.cost.model, translated to VTIME_PER_SEC / flushiops like the other iops coefficients, and falling back to the write coefficients when unset. On virtio-blk, flushiops=10 throttles a flush storm to one flush per 100ms, which is exactly the intended budget. Parameter naming and whether the builtin profiles and autocalibration should learn it are better discussed on that thread.