From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-100.freemail.mail.aliyun.com (out30-100.freemail.mail.aliyun.com [115.124.30.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D44ED3C39 for ; Mon, 30 Sep 2024 02:07:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.100 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727662063; cv=none; b=OlVwe8dA90ZU7aHdcra9PJceOEoLZqc6Z4S4vTjl038I32OoE1C6vJWCfYkniclYRtUrCFZ7AofDWTY2a20tExDWbx8idO74UkZg7gjLCVmBXoOItserzXHp8iuBlrryNQq0H/q7VRC2V+4XiMnKaxztCmETVPjnRUquoo1tqiE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727662063; c=relaxed/simple; bh=pPTJSgUlI24z7CYUY9r/cExRWMY2OVH/cPi4xsuzPoQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=kCyGTXA+OlR6a5pgVCGPiZzcvl0yOimSJI3veCdthTLJ1seBvyaCyoGkQgxSfIcNMFmJxkPCW5YP8DOoY5FG8lxHwzi0u4oNvUBIe1LoxbZf6luXRdcYBmAeAfslNKa33Zfk5FwGWZUXUh3Mh1xgaWaPpi0oNZolrqvcvRrnEs0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=oMQaTf3i; arc=none smtp.client-ip=115.124.30.100 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="oMQaTf3i" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1727662052; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=ldefraz5rFyL/LLYuTatQoVMo2Z9oXl/AKXIrt0zCQc=; b=oMQaTf3iorzqohDsxY7Fv7ZdrBPHgN6M8Jf4gxLI9TaP5eftyzYhHA5QtcnGTF0Y4qjjYwtafK9MibXaTEvu8g4dYtRgvp00BoMHMFIZsS0c3f5eeyDnSYa7lg4ubB8GfRDpyrH205of7Tu4lSlPNx/CyruG0ZYMSMp2CBrFe5I= Received: from 30.74.144.111(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WFxLnGU_1727661733) by smtp.aliyun-inc.com; Mon, 30 Sep 2024 10:02:13 +0800 Message-ID: <1e5357de-3356-4ae7-bc69-b50edca3852b@linux.alibaba.com> Date: Mon, 30 Sep 2024 10:02:11 +0800 Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] tmpfs: fault in smaller chunks if large folio allocation not allowed To: Matthew Wilcox , "Pankaj Raghav (Samsung)" Cc: Kefeng Wang , Andrew Morton , Hugh Dickins , Alexander Viro , Christian Brauner , Jan Kara , Anna Schumaker , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org References: <20240914140613.2334139-1-wangkefeng.wang@huawei.com> <20240920143654.1008756-1-wangkefeng.wang@huawei.com> <1d4f98aa-f57d-4801-8510-5c44e027c4e4@huawei.com> From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2024/9/26 21:52, Matthew Wilcox wrote: > On Thu, Sep 26, 2024 at 10:38:34AM +0200, Pankaj Raghav (Samsung) wrote: >>> So this is why I don't use mapping_set_folio_order_range() here, but >>> correct me if I am wrong. >> >> Yeah, the inode is active here as the max folio size is decided based on >> the write size, so probably mapping_set_folio_order_range() will not be >> a safe option. > > You really are all making too much of this. Here's the patch I think we > need: > > +++ b/mm/shmem.c > @@ -2831,7 +2831,8 @@ static struct inode *__shmem_get_inode(struct mnt_idmap *idmap, > cache_no_acl(inode); > if (sbinfo->noswap) > mapping_set_unevictable(inode->i_mapping); > - mapping_set_large_folios(inode->i_mapping); > + if (sbinfo->huge) > + mapping_set_large_folios(inode->i_mapping); > > switch (mode & S_IFMT) { > default: IMHO, we no longer need the the 'sbinfo->huge' validation after adding support for large folios in the tmpfs write and fallocate paths [1]. Kefeng, can you try if the following RFC patch [1] can solve your problem? Thanks. (PS: I will revise the patch according to Matthew's suggestion) [1] https://lore.kernel.org/all/c03ec1cb1392332726ab265a3d826fe1c408c7e7.1727338549.git.baolin.wang@linux.alibaba.com/