Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3759896pxb; Sun, 7 Feb 2021 22:14:55 -0800 (PST) X-Google-Smtp-Source: ABdhPJxmF7VZN7NaKD3siExWmvKMiVMRGvktu8CrRyUTNqKZaMiaBudtfnumBuP7ga0LpKtk6TaS X-Received: by 2002:a17:906:364e:: with SMTP id r14mr15734464ejb.266.1612764895403; Sun, 07 Feb 2021 22:14:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612764895; cv=none; d=google.com; s=arc-20160816; b=sKI4CgDmCxitff+EH5OXXCx6Hie3o3roT2r693gFoVaCRTAwgmCQKm64jNPPEpq5W+ VkxxXCsOuB6h8Pp5WoYNomY0jm/Yv+zo3bPYvJUQG4212WoFMgv8O6fT4q9qr5EEcm1n C4KN2PxGVNKqktgSy86UJsen60oN6VtbgUVSOfrxngkEqU060hqFkGb+jk6YeJNhSOKu LmVQy8HzjOwrV81l3lKvBI2cZttWqI0U4ivBfuiBxfl35s4Zx1vWKGL/vCImLkAB+drV oiklJll1mp4VfyHTYMaBar+gqXeohBsMFvn2o9tShgEqH4aC2k/5jr5I5IBpIFuzHZmt Na0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=sK9eeXoIQ7dVL5SszGZOiwXsGs1463wflzG5D3nYUVk=; b=KIFP8SkrDAcDbMKNum8OmAV6H8TIxHBJXAShcLdizqZcZkwwa/G7YXHj/HZGo4Ue1N PIHN6LbZZos/cVjZrlYj6XNfFeLi0KErFO2YBwMijyHrElUQ4sPdHdklkWbWAgmhPYhA 7nyty5JWZIZ92XQwge8iCGlJSMYrgLNaYPI/cwbnT9gDDEOAqiVc/f/yNAFQfGfXEQ/L NgT1VfFVEv0uv3WEFEu2lPmssF3CvUGHOluYuutSzwwFVZmujUGNRoGJr2qBu6f7Fji/ lpBotZt9nKFyeXADfdXLHqamWnwxAvxI3qpIXEZUYsDsuQsW9D4vyQKaY+t8QargK8sn Fz+A== 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 g9si10475750ejj.456.2021.02.07.22.14.32; Sun, 07 Feb 2021 22:14:55 -0800 (PST) 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 S229550AbhBHGNK (ORCPT + 99 others); Mon, 8 Feb 2021 01:13:10 -0500 Received: from szxga06-in.huawei.com ([45.249.212.32]:12460 "EHLO szxga06-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229626AbhBHGNE (ORCPT ); Mon, 8 Feb 2021 01:13:04 -0500 Received: from DGGEMS404-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4DYwdF4CldzjK9j; Mon, 8 Feb 2021 14:11:13 +0800 (CST) Received: from [10.67.77.175] (10.67.77.175) by DGGEMS404-HUB.china.huawei.com (10.3.19.204) with Microsoft SMTP Server id 14.3.498.0; Mon, 8 Feb 2021 14:12:10 +0800 Subject: Re: [PATCH] fs/buffer.c: Add checking buffer head stat before clear To: Andrew Morton CC: , , Yang Guo , Alexander Viro , Nick Piggin References: <1612332890-57918-1-git-send-email-zhangshaokun@hisilicon.com> <20210205154548.49dd62b161b794b9f29026f1@linux-foundation.org> From: Shaokun Zhang Message-ID: Date: Mon, 8 Feb 2021 14:12:10 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20210205154548.49dd62b161b794b9f29026f1@linux-foundation.org> Content-Type: text/plain; charset="gbk" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.77.175] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Andrew, ?? 2021/2/6 7:45, Andrew Morton ะด??: > On Wed, 3 Feb 2021 14:14:50 +0800 Shaokun Zhang wrote: > >> From: Yang Guo >> >> clear_buffer_new() is used to clear buffer new stat. When PAGE_SIZE >> is 64K, most buffer heads in the list are not needed to clear. >> clear_buffer_new() has an enpensive atomic modification operation, >> Let's add checking buffer head before clear it as __block_write_begin_int >> does which is good for performance. > > Did this produce any measurable improvement? It has been tested on Huwei Kunpeng 920 which is ARM64 platform and test commond is below: numactl --cpunodebind=0 --membind=0 fio -name=randwrite -numjobs=16 -filename=/mnt/test1 -rw=randwrite -ioengine=libaio -direct=0 -iodepth=64 -sync=0 -norandommap -group_reporting -runtime=60 -time_based -bs=4k -size=5G The test result before patch: WRITE: bw=930MiB/s (976MB/s), 930MiB/s-930MiB/s (976MB/s-976MB/s), io=54.5GiB (58.5GB), run=60001-60001msec The test result after patch: WRITE: bw=958MiB/s (1005MB/s), 958MiB/s-958MiB/s (1005MB/s-1005MB/s), io=56.1GiB (60.3GB), run=60001-60001msec > > Perhaps we should give clear_buffer_x() the same optimization as > set_buffer_x()? > Good catch, but we check it more about it, if we do it the same as set_buffer_x(), many more codes will be fixed, such as ext4_wait_block_bitmap it has done sanity check using buffer_new and clear_buffer_new will check it again. Thanks, Shaokun > > static __always_inline void set_buffer_##name(struct buffer_head *bh) \ > { \ > if (!test_bit(BH_##bit, &(bh)->b_state)) \ > set_bit(BH_##bit, &(bh)->b_state); \ > } \ > static __always_inline void clear_buffer_##name(struct buffer_head *bh) \ > { \ > clear_bit(BH_##bit, &(bh)->b_state); \ > } \ > > > . >