Received: by 2002:a25:d783:0:0:0:0:0 with SMTP id o125csp157298ybg; Wed, 18 Mar 2020 19:38:59 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsVLMJ5vn2blrEzxBAymgYPQ5aevw4b0EbsXI2hsv8/abwHWtFbj/ZkK7AfsEXaxcftBTrl X-Received: by 2002:a9d:6354:: with SMTP id y20mr554738otk.171.1584585538960; Wed, 18 Mar 2020 19:38:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584585538; cv=none; d=google.com; s=arc-20160816; b=nOqshw+brJHwAj3FBjV/3gqtZLp5wqfLgU/RawiwhWVylbmBCZOQcFTdshtPefSF1T C4+HFbib+FpqQ36LPwcEOpJwiuM42BhzlpfhqFIDsBP2rhXAFg2FDoRqL28AfftMGdHu E34+WMrDdx30WCNdTC82kVywe1pbArIXSGIFBtDqbg6KAYquxDi/4e56DW/iDUjurYfJ ih+73LD42hGguMyaRzhAQHZR4IJrIKzA+lALcc7ZiJiwlJ4ksGpKoTziI1IF4KYVwPZY y8S9UkqdPnz2QZ0xTI+yn+cVh/ChnvlHwvNAsYDlCEL2Fbv0QB7fkPD/6mxwI8WkvbTC jp8A== 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; bh=rA9A7+oDBZw1gVo7OjOl/6Q6sHkbxSPtFtiwft3+qxI=; b=TN8qGTpTCzg3QwjY8/UAJpz908MJQTsmNoNJem13rCrhyKNEGkCT/RlEvwu79XZUPn ndHFSrQXYtDrGrmewTE+gSovpQ+zMbEZDvW/56b4tqG3WzRwh9UeDTdBthGhysTPifDI i5GYBq+iHsk1sKsZmZX+EyOqrMWtXTdTiW1ufGbUZCDBB06jdqwu20vV6pqWiUeYVLl5 3g2IQVbNbCEXFr00FBvXnmUXe79h5CI8QWk1eq6/C/zlzLyOpFdC/SezLwS4kP2U6ODx vFlYIgROVn9pr+tsW1TeDbT/Cpx8wpOctBLvWo1MYwqxbT8m/VKfW2dkv+MF3/O2FyaE 4Miw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o7si526392ote.134.2020.03.18.19.38.45; Wed, 18 Mar 2020 19:38:58 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726726AbgCSChT (ORCPT + 99 others); Wed, 18 Mar 2020 22:37:19 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:11718 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726623AbgCSChT (ORCPT ); Wed, 18 Mar 2020 22:37:19 -0400 Received: from DGGEMS402-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 485D598D51686BB0ABD9; Thu, 19 Mar 2020 10:37:12 +0800 (CST) Received: from [10.134.22.195] (10.134.22.195) by smtp.huawei.com (10.3.19.202) with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 19 Mar 2020 10:37:07 +0800 Subject: Re: [PATCH v2] f2fs: use kmem_cache pool during inline xattr lookups To: Ju Hyung Park CC: Jaegeuk Kim , , , Chao Yu References: <20200225101710.40123-1-yuchao0@huawei.com> From: Chao Yu Message-ID: <08d03473-9871-ba10-4626-58c4479ef9d1@huawei.com> Date: Thu, 19 Mar 2020 10:37:06 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.134.22.195] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Ju Hyung, On 2020/3/18 20:14, Ju Hyung Park wrote: > Hi Chao. > > I got the time around to test this patch. > The v2 patch seems to work just fine, and the code looks good. Thanks a lot for the review and test. > > On Tue, Feb 25, 2020 at 7:17 PM Chao Yu wrote: >> diff --git a/fs/f2fs/xattr.c b/fs/f2fs/xattr.c >> index a3360a97e624..e46a10eb0e42 100644 >> --- a/fs/f2fs/xattr.c >> +++ b/fs/f2fs/xattr.c >> @@ -23,6 +23,25 @@ >> #include "xattr.h" >> #include "segment.h" >> >> +static void *xattr_alloc(struct f2fs_sb_info *sbi, int size, bool *is_inline) >> +{ >> + *is_inline = (size == sbi->inline_xattr_slab_size); > > Would it be meaningless to change this to the following code? > if (likely(size == sbi->inline_xattr_slab_size)) > *is_inline = true; > else > *is_inline = false; Yup, I guess it's very rare that user will change inline xattr size via remount, so I'm okay with this change. Jaegeuk, Could you please help to update the patch in your git tree directly? Thanks, > > The above statement seems to be only false during the initial mount > and the rest(millions) seems to be always true. > > Thanks. > . >