Received: by 2002:a05:6358:bb9e:b0:b9:5105:a5b4 with SMTP id df30csp482487rwb; Fri, 2 Sep 2022 18:30:00 -0700 (PDT) X-Google-Smtp-Source: AA6agR6i6u6tacOSGN9MxaHnoLsrSSW516GMhfeQdD6PpdqcrLZM2QFrR10rySRVYe+csGqRcgvg X-Received: by 2002:a17:907:a426:b0:73d:9d53:b33 with SMTP id sg38-20020a170907a42600b0073d9d530b33mr28892180ejc.116.1662168600608; Fri, 02 Sep 2022 18:30:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662168600; cv=none; d=google.com; s=arc-20160816; b=IQCxX+uzjMSKkdOJCoQc3DQ5tfBt1qgBFzX3JRN3KLt62tvokeavwnwKTm1WHpRsb2 DE7lfnCPiVxLdi6zg/lwncWLnlaaRR04M61hjWLnMjZenJi1DGtkXNXZueev9WJZEm9s A+zE3xTWPb2jJnNfmEI4Zc+ibE5omixZW21SivFkWD30B3/oFinZ9V8MZ0ItoiNTtS/X iQpjF1uEdBwRXzHmeGctRoXAcrKRg9vN64V51IYXH9fUuaEUUuUGtGEJZDRD3NKYGX8V 0Qn4vGa7ZUNydCijIpNJS/Yqk76PNjEnMJ68jRLz+9+lJ0OdHh/5/HPDt8JXcvpktK/4 uxnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=jP6EPggHjkZX1NaV9U8a8QOu1uLproFoHSDlqllEgzg=; b=Nm2D868we2Vz0Dhtg8321nj6KMCFyz9K1KvxRJ98XNBEqU84o/JbSCJYJBj6c4qkmP +d/jRnpg3was+/Qmo3ghkwZNlDtfEB6hELk0g7OijAzF5+oS4oH7AZe2A6Z2L7P0Dt4k uhKfEUvxv/xQOlZVxS0RYTJkn2/+3VFyX9Ffrejpy/3htT9lXc9z6VEB7+5gJnGZRN3E QwQUoFUc0WMn6UfC4s+iXk6J7GC2DnRXOgcY8WBZAaBPpLg5YkFZYCSKv1DT1zCP4nFb UAE1A/xRB6v3b3PJUobGvUNyrhB90cczOAovKa8Cm56XMcs+zEIsIBkvTnG0VM6QRFqH v42Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=HEhKmQ7g; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j2-20020a170906430200b007304a1ee3e3si2566802ejm.517.2022.09.02.18.29.24; Fri, 02 Sep 2022 18:30:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=HEhKmQ7g; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229586AbiICBYs (ORCPT + 99 others); Fri, 2 Sep 2022 21:24:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41324 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229508AbiICBYs (ORCPT ); Fri, 2 Sep 2022 21:24:48 -0400 Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2C8811C103 for ; Fri, 2 Sep 2022 18:24:45 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id d12so3451410plr.6 for ; Fri, 02 Sep 2022 18:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date; bh=jP6EPggHjkZX1NaV9U8a8QOu1uLproFoHSDlqllEgzg=; b=HEhKmQ7gwK/HxPmpwnIWy4QlrEFl9/wj4w99hLp/jVkhQLgZ4BAmC76DOTiCqRjsDr fZiLkszhkXerCXtNDQLNeXW1GK3grzipGrmPCQkBVgNn0+S9w2zh5nIa+W5kpdZEwKSu 0i4UIFEZqLZAm8d4Jtdw4nUGMB0wMY12p9HUEmuRkxF1ybhxrIg3uAFswaj+QR2ODU4k nLTL9W45u7hJ3vfGnUikejtAJts46K+2IZKiBObrqrnR8CFOys0o04MzBWJYKX9ByATv FbKqt59LgeJs6PO3Fpfgmv9lSJWaCjB6BiK22ChN/bjbUJ0nH5cHRENg0IxCSxxbBb3L abBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date; bh=jP6EPggHjkZX1NaV9U8a8QOu1uLproFoHSDlqllEgzg=; b=sXUFiFkmNCslXZ3ATMxQj8tPkRcAthSAmLK5bdP/s4+ur9dWR/1QJAshQsKGxny6z3 x3WOz9mNTS5pOahJge9rZxzwsaWLQFTMLcUl8LLpj9/RcvH8GzVtNFHUW2c5cTxS5N+s Ibi86HqihEQNDL4JYjOmLkxGoqBTnO6ZaYT0tNnx9E0nBwNVZffcQ/yPAo5TykJzZ1Dm iCR4VKR0iYfMVxSDkFaO0v7iXV0Kb5gucj8zBll/Dxtf0CpNoNgu9l6p2B7vTxl0zWy3 CEGUaqb1X/KSvTB7ZPAFDTvQR9YLHxf4Cibcalkr4BvQNxu6oJze+ccsnBK3z5GfP7tr eMaw== X-Gm-Message-State: ACgBeo2LC70gJFnrSxQTaHgtVnq8V97BdhiQiJ6QZd97b1TQoRqC2i+w xOyOzpzwIuu/h/tPAFKl/+Yj9w== X-Received: by 2002:a17:902:e94c:b0:171:3df0:c886 with SMTP id b12-20020a170902e94c00b001713df0c886mr39349023pll.39.1662168284652; Fri, 02 Sep 2022 18:24:44 -0700 (PDT) Received: from C02GD5ZHMD6R.bytedance.net ([139.177.225.238]) by smtp.gmail.com with ESMTPSA id d7-20020a170902654700b00172ba718ed4sm2262494pln.138.2022.09.02.18.24.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Sep 2022 18:24:43 -0700 (PDT) From: Jinke Han X-Google-Original-From: Jinke Han To: tytso@mit.edu, adilger.kernel@dilger.ca Cc: linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, yi.zhang@huawei.com, Jinke Han Subject: [PATCH v2] ext4: place buffer head allocation before handle start Date: Sat, 3 Sep 2022 09:24:29 +0800 Message-Id: <20220903012429.22555-1-hanjinke.666@bytedance.com> X-Mailer: git-send-email 2.32.0 (Apple Git-132) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org From: Jinke Han In our product environment, we encounter some jbd hung waiting handles to stop while several writters were doing memory reclaim for buffer head allocation in delay alloc write path. Ext4 do buffer head allocation with holding transaction handle which may be blocked too long if the reclaim works not so smooth. According to our bcc trace, the reclaim time in buffer head allocation can reach 258s and the jbd transaction commit also take almost the same time meanwhile. Except for these extreme cases, we often see several seconds delays for cgroup memory reclaim on our servers. This is more likely to happen considering docker environment. One thing to note, the allocation of buffer heand is as often as page allocation or more often when blocksize less than page size. Just like page cache allocation, we should also place the buffer head allocation before startting the handle. After commit:cc883236b792, no nore need to do for delay alloc path, just do it for no delay alloc code. Signed-off-by: Jinke Han --- fs/ext4/inode.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 601214453c3a..0d6c4ec7c840 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -1188,6 +1188,13 @@ static int ext4_write_begin(struct file *file, struct address_space *mapping, page = grab_cache_page_write_begin(mapping, index); if (!page) return -ENOMEM; + /* + * The same as page allocation, we prealloc buffer heads before + * starting the handle. + */ + if (!page_has_buffers(page)) + create_empty_buffers(page, inode->i_sb->s_blocksize, 0); + unlock_page(page); retry_journal: -- 2.20.1