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 X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 22425C32771 for ; Thu, 16 Jan 2020 00:01:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F388C2084D for ; Thu, 16 Jan 2020 00:01:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729016AbgAPABC (ORCPT ); Wed, 15 Jan 2020 19:01:02 -0500 Received: from mx2.suse.de ([195.135.220.15]:42166 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728931AbgAPABC (ORCPT ); Wed, 15 Jan 2020 19:01:02 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 451B3AD0F; Thu, 16 Jan 2020 00:01:00 +0000 (UTC) Subject: Re: [PATCH] bcache: back to cache all readahead I/Os To: Nix Cc: Eric Wheeler , linux-bcache@vger.kernel.org, stable@vger.kernel.org References: <20200104065802.113137-1-colyli@suse.de> <87lfqa2p4s.fsf@esperi.org.uk> <5af6593d-b6aa-74a7-0aae-e3c689cebc67@suse.de> <875zhc3ncu.fsf@esperi.org.uk> From: Coly Li Organization: SUSE Labs Message-ID: <931567a8-a81d-a1cd-c7d8-7c193e61f79d@suse.de> Date: Thu, 16 Jan 2020 08:00:53 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <875zhc3ncu.fsf@esperi.org.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On 2020/1/15 8:39 下午, Nix wrote: > On 15 Jan 2020, Coly Li stated: > >> I have two reports offline and directly to me, one is from an email >> address of github and forwarded to me by Jens, one is from a China local >> storage startup. >> >> The first report complains the desktop-pc benchmark is about 50% down >> and the root cause is located on commit b41c9b0 ("bcache: update >> bio->bi_opf bypass/writeback REQ_ flag hints"). >> >> The second report complains their small file workload (mixed read and >> write) has around 20%+ performance drop and the suspicious change is >> also focused on the readahead restriction. >> >> The second reporter verifies this patch and confirms the performance >> issue has gone. I don't know who is the first report so no response so far. > > Hah! OK, looks like readahead is frequently-enough useful that caching > it is better than not caching it :) I guess the problem is that if you > don't cache it, it never gets cached at all even if it was useful, so > the next time round you'll end up having to readahead it again :/ > Yes, this is the problem. The bypassed data won't have chance to go into cache always. > One wonders what effect this will have on a bcache-atop-RAID: will we > end up caching whole stripes most of the time? > In my I/O pressure testing, I have a raid0 backing device assembled by 3 SSDs. From my observation, the whole stripe size won't be cached for small read/write requests. The stripe size alignment is handled in md raid layer, even md returns bio which stays in a stripe size memory chunk, bcache only takes bi_size part for its I/O. Thanks. -- Coly Li