From patchwork Fri Apr 28 15:02:27 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Charan Teja Kalla X-Patchwork-Id: 13226609 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 95D75C77B60 for ; Fri, 28 Apr 2023 15:40:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F21A06B0071; Fri, 28 Apr 2023 11:40:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ED1736B0074; Fri, 28 Apr 2023 11:40:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D72D46B0075; Fri, 28 Apr 2023 11:40:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id C519E6B0071 for ; Fri, 28 Apr 2023 11:40:10 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 6213C80248 for ; Fri, 28 Apr 2023 15:40:10 +0000 (UTC) X-FDA: 80731210980.08.D320866 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by imf20.hostedemail.com (Postfix) with ESMTP id 2947C1C0010 for ; Fri, 28 Apr 2023 15:40:07 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=nKjktdGV; spf=pass (imf20.hostedemail.com: domain of quic_charante@quicinc.com designates 205.220.180.131 as permitted sender) smtp.mailfrom=quic_charante@quicinc.com; dmarc=pass (policy=none) header.from=quicinc.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682696408; a=rsa-sha256; cv=none; b=xDikQfE947x0pwNNdu49YxdVVVPc37co9N7wzIMUQdCPKyIJWPizO9wF4IgNSrC2aBw7o8 PDU4oue8FZ9fgPpcDUAr6U4F0NzC4EONe0+5GdKgvXt8a1YdPPUPLTvhYbbBSF670wg5Dy zoO/47eURLOn7CZwsUrK3T24Om7xXxE= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=nKjktdGV; spf=pass (imf20.hostedemail.com: domain of quic_charante@quicinc.com designates 205.220.180.131 as permitted sender) smtp.mailfrom=quic_charante@quicinc.com; dmarc=pass (policy=none) header.from=quicinc.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682696408; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=GjdL63RtZMlFerOhVgECcz++9zg0UdD0TUKzlrJonvg=; b=8fSvBjsspkRqIt83u2vPWj8l/IBBe9UuqZhe+wY3gtaMLKTqWrODrxjUfPeoWYD+HsNPAM nTcOENQKg80EG2anz7dXJnKsqhT89Z3v5BQVX/eSO+vo8VlSEK3WeWGrY9Gy71W6UN1QwO gBuoF//0RX6wjJ1RNEP6nMfucxcD9N0= Received: from pps.filterd (m0279869.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 33SDvnOD024817; Fri, 28 Apr 2023 15:03:03 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=qcppdkim1; bh=GjdL63RtZMlFerOhVgECcz++9zg0UdD0TUKzlrJonvg=; b=nKjktdGVvpaZEyMlUGtUTqSXDnVNgSMBinN2rNX4x8Hhobe43f/r3FcAeT6P52Litw/f 81FDUC9OJ8lzQjYb7TR8ywdlrAGM6Pl5MlnbRutG0Gemks7YfhuAbKpjs00q459VGHDr yWuNlblV4rRiepjUxm1avQGsvyFVlbZej/6axiG5aLz8l+MljpNLLadYD+h43tq80yZF eb7THlrX2CTGn0cBfutvA6Piip4/0r11g26cZDlKVsOyvF21LAhDoAEHlAvqGlzCoiGu u1eNawWPa4Enc9xrZ3LaxEnH6d03hRrEhdMnVCi0/mXX5E5IGYhu6YcHNYzH5sfUorM8 iw== Received: from nalasppmta02.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3q7thv3d1p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Apr 2023 15:03:02 +0000 Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA02.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 33SF31FY020244 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Apr 2023 15:03:01 GMT Received: from hu-charante-hyd.qualcomm.com (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.42; Fri, 28 Apr 2023 08:02:57 -0700 From: Charan Teja Kalla To: , , , , , , , , CC: , , Charan Teja Kalla Subject: [PATCH V8 2/2] mm: shmem: implement POSIX_FADV_[WILL|DONT]NEED for shmem Date: Fri, 28 Apr 2023 20:32:27 +0530 Message-ID: <4acf1d89f58167292b9ec47507d68ff6b7057a28.1682692818.git.quic_charante@quicinc.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: References: MIME-Version: 1.0 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01a.na.qualcomm.com (10.47.209.196) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: vFgVdY9KiRpcK2gNcbmi_I215EMU0aSu X-Proofpoint-ORIG-GUID: vFgVdY9KiRpcK2gNcbmi_I215EMU0aSu X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-04-28_04,2023-04-27_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 bulkscore=0 malwarescore=0 lowpriorityscore=0 suspectscore=0 mlxscore=0 phishscore=0 spamscore=0 adultscore=0 priorityscore=1501 mlxlogscore=999 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000 definitions=main-2304280120 X-Rspam-User: X-Rspamd-Queue-Id: 2947C1C0010 X-Rspamd-Server: rspam01 X-Stat-Signature: jktz7bztjma7ngpfsda9hm1bxe6x8igz X-HE-Tag: 1682696407-760934 X-HE-Meta: U2FsdGVkX1+GWyp73zDEn5Dm02oNUuNZaM3YrrDq9NSCZetjHj5U1mF25x4zVaIvRjIa4RHNGFg49Fa29qDpMrhCgBG51544FtW8uhaphhHvQOun4Tur3oamjvCz2pF57hrndhvO/CgbmI58/tqwNw98knVbc14Unn339lw7oUzFfESw87CG41CAkhk+s4t2ysaHk5JoCynv/z2Kgdx1UvBfWCXzGt34LAybFih2uvOjjLuAwaNGpVK20vxzhvVh36p0n9jAktgihmLnDbqoaKIt4a1J9s7IMXd9gVJTmIrVAP2FhfzY0demO3L0HwnDlQs1CCYRqBhR4FvXF+f4/ttkfMNPgkQInZlWi+hPdG6kOMyttrIJdpUdtdRRE6fFvL6MG39nxcOnvbUYn4FyHUcihqrsLhi2WuyLb3BbSA2lkovEtTuc4eFHXUEz/yHq0vzexLWuv5HCg2X8jDm/qiXxAhb6bKcNcGb31HzkOPQYelfdlgvHZh4KZZgd/6k2nXtVyc3093SPbcQ7a96ay0Cfyq0OeV+EAO3OdjCQ0Ao4cEaug8RuGPkXLR+wZ2vaW5HZvIbQv84rn2vpRd0jWMQ7IPcnW91oqhuF7FXgb1+hjLgyeU9xVOeipA6vS5axH2s+9zdYmWn4NZnaRgFRIpq+0Cakys7jZcWOOkkM2CD+rjwYlVJ1pfutlCwB7SsBemYpzzTM1gWJOi59zupepFhGQgMCF6TEGN1fsBzn9LSeTi2ZmxfP7yP3GgTPd3kkS9sluANWSr10oL7reCYjx5aOHMR5e32fICsbyntzwZU5mn9L2qvbrYer9vj7zAH4tohLWU9VyPFOdXiFBli1JhB+MQyNMTa00yRv/HJ3NWOqjE2BHXML7pKqpP4QldYv22NjoWhwGTkwYHFKlykM8EtjPZQQqUIEofBFx7HXs6ZUtF+kxSbcPGRlMDD8G6HKss1i6ZUT2qMyXsWDC9d pV8MRjKk wyWna5KTB7cROd9Xo2O/QeRus7+WmDLgOG2/UlVPHqI25oqrbNI+0T8qHgHNbomQCqOh6nx0YnA72y4gkt4UH8/SWBobDQCZ/nnNfIz5wej/scS4XOuyDY0Immm3mBa9RzIFzA9reClp4pUIqfuDqeqdyX//Bz+u8GeHUR/Sq0leIlyHdmCE1qjOwRdPsK8krp7um0izfT62DqWgC/c6Hpog1IjpfvmZdahjoQdtMWpMv722fnscNkwMMyxRlz9/CV3UUECngkrfqIKH4A9Ar1qR+6VFyODBHtJQbD+Wm69dXZtvFFXRA5hvQvFQfnLPYjQDr2S0bY56gLQ/ZYV0saZ20G2BX1M+2rllpIIEOTJ4em1crZIR4lc43eW4ql5AskEtJC80P9AHUbAopKLmqRqSQmD7GoUyqPNNg1AVl5WALcoi4vLy50IllaDEhaGhwyIY1tsNKufUpKJ2qG2sdUd3PRPLVId//STu3tQqMWxusSZs9XXfMSgY5U/cyIt8IqMbIShnKyuRwTF30XgF/WFr6L33WNt7GiGc7vu1wkZPvrkVQexthc05xbavH3y/UBorrRb8Z932Yh1pqUtrD4LBFO128fb2idJ9HxHma+bUUcuQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Currently fadvise(2) is supported only for the files that doesn't associated with noop_backing_dev_info thus for the files, like shmem, fadvise results into NOP. But then there is file_operations->fadvise() that lets the file systems to implement their own fadvise implementation. Use this support to implement some of the POSIX_FADV_XXX functionality for shmem files. This patch aims to implement POSIX_FADV_WILLNEED and POSIX_FADV_DONTNEED advises to shmem files which can be helpful for the clients who may want to manage the shmem pages of the files that are created through shmem_file_setup[_with_mnt](). One usecase is implemented on the Snapdragon SoC's running Android where the graphics client is allocating lot of shmem pages per process and pinning them. When this process is put to background, the instantaneous reclaim is performed on those shmem pages using the logic implemented downstream[3][4]. With this patch, the client can now issue the fadvise calls on the shmem files that does the instantaneous reclaim which can aid the use cases like mentioned above. Application that does require the reclaimed pages, say when the app put to foreground, can issue the POSIX_FADV_WILLNEED to bring back them from the swap area. Alternatively the drivers can also use shmem_read_mapping_page_gfp() to bring back the reclaimed shmem pages. This usecase lead to ~2% reduction in average launch latencies of the apps and 10% in total number of kills by the low memory killer running on Android. Currently we are not supporting the mapped pages which can be implemented as a next step[5]. Some questions asked while reviewing this patch: Q) Can the same thing be achieved with FD mapped to user and use madvise? A) All drivers are not mapping all the shmem fd's to user space and want to manage them with in the kernel. Ex: shmem memory can be mapped to the other subsystems and they fill in the data and then give it to other subsystem for further processing, where, the user mapping is not at all required. A simple example, memory that is given for gpu subsystem which can be filled directly and give to display subsystem. And the respective drivers know well about when to keep that memory in ram or swap based on may be a user activity. Q) Should we add the documentation section in Manual pages? A) The man[1] pages for the fadvise() whatever says is also applicable for shmem files. so couldn't feel it correct to add specific to shmem files separately. Q) The proposed semantics of POSIX_FADV_DONTNEED is actually similar to MADV_PAGEOUT and different from MADV_DONTNEED. This is a user facing API and this difference will cause confusion? A) man pages [2] says that "POSIX_FADV_DONTNEED attempts to free cached pages associated with the specified region." This means on issuing this FADV, it is expected to free the file cache pages. And it is implementation defined If the dirty pages may be attempted to writeback. And the unwritten dirty pages will not be freed. So, FADV_DONTNEED also covers the semantics of MADV_PAGEOUT for file pages and there is no purpose of PAGEOUT for file pages. [1] https://linux.die.net/man/2/fadvise [2] https://man7.org/linux/man-pages/man2/posix_fadvise.2.html [3] https://git.codelinaro.org/clo/la/platform/vendor/qcom/opensource/graphics-kernel/-/blob/gfx-kernel.lnx.1.0.r3-rel/kgsl_reclaim.c#L289 [4] https://android.googlesource.com/kernel/common/+/refs/heads/android12-5.10/mm/shmem.c#4310 [5] https://lore.kernel.org/all/CAPTztWZ-PTmF=AazhCuC3u-Ca_mY+QsJGgMdu4W0DC05zk3-iA@mail.gmail.com/ Signed-off-by: Charan Teja Kalla --- mm/shmem.c | 127 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 127 insertions(+) diff --git a/mm/shmem.c b/mm/shmem.c index 448f393..07e33f2 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -40,6 +40,9 @@ #include #include #include +#include +#include +#include #include "swap.h" static struct vfsmount *shm_mnt; @@ -2538,6 +2541,129 @@ int shmem_mfill_atomic_pte(struct mm_struct *dst_mm, static const struct inode_operations shmem_symlink_inode_operations; static const struct inode_operations shmem_short_symlink_operations; +static void shmem_isolate_pages_range(struct address_space *mapping, pgoff_t start, + pgoff_t end, struct list_head *list) +{ + XA_STATE(xas, &mapping->i_pages, start); + struct folio *folio; + + rcu_read_lock(); + xas_for_each(&xas, folio, end) { + if (xas_retry(&xas, folio)) + continue; + if (xa_is_value(folio)) + continue; + + if (!folio_try_get(folio)) + continue; + if (folio_test_unevictable(folio) || folio_mapped(folio) || + !folio_isolate_lru(folio)) { + folio_put(folio); + continue; + } + folio_put(folio); + + /* + * Prepare the folios to be passed to reclaim_pages(). + * VM can't reclaim a folio unless young bit is + * cleared in its flags. + */ + folio_clear_referenced(folio); + folio_test_clear_young(folio); + list_add(&folio->lru, list); + if (need_resched()) { + xas_pause(&xas); + cond_resched_rcu(); + } + } + rcu_read_unlock(); +} + +static void shmem_fadvise_dontneed(struct address_space *mapping, pgoff_t start, + pgoff_t end) +{ + LIST_HEAD(folio_list); + + if (!total_swap_pages || mapping_unevictable(mapping)) + return; + + lru_add_drain(); + shmem_isolate_pages_range(mapping, start, end, &folio_list); + reclaim_pages(&folio_list); +} + +static void shmem_fadvise_willneed(struct address_space *mapping, + pgoff_t start, pgoff_t end) +{ + struct folio *folio; + pgoff_t index; + + xa_for_each_range(&mapping->i_pages, index, folio, start, end) { + if (!xa_is_value(folio)) + continue; + folio = shmem_read_folio(mapping, index); + if (!IS_ERR(folio)) + folio_put(folio); + } +} + +static int shmem_fadvise(struct file *file, loff_t offset, loff_t len, int advice) +{ + loff_t endbyte; + pgoff_t start_index; + pgoff_t end_index; + struct address_space *mapping; + struct inode *inode = file_inode(file); + int ret = 0; + + if (S_ISFIFO(inode->i_mode)) + return -ESPIPE; + + mapping = file->f_mapping; + if (!mapping || len < 0 || !shmem_mapping(mapping)) + return -EINVAL; + + endbyte = fadvise_calc_endbyte(offset, len); + + switch (advice) { + case POSIX_FADV_DONTNEED: + /* + * Look at the documentation in the generic_fadvise() for + * the reasoning behind these calculations. + */ + start_index = (offset+(PAGE_SIZE-1)) >> PAGE_SHIFT; + end_index = (endbyte >> PAGE_SHIFT); + + if ((endbyte & ~PAGE_MASK) != ~PAGE_MASK && + endbyte != inode->i_size - 1) { + if (end_index == 0) + break; + end_index--; + } + + if (end_index >= start_index) + shmem_fadvise_dontneed(mapping, start_index, end_index); + break; + case POSIX_FADV_WILLNEED: + start_index = offset >> PAGE_SHIFT; + end_index = endbyte >> PAGE_SHIFT; + shmem_fadvise_willneed(mapping, start_index, end_index); + break; + case POSIX_FADV_NORMAL: + case POSIX_FADV_RANDOM: + case POSIX_FADV_SEQUENTIAL: + case POSIX_FADV_NOREUSE: + /* + * No bad return value, but ignore advice. + */ + break; + default: + return -EINVAL; + } + + return ret; +} + static int shmem_write_begin(struct file *file, struct address_space *mapping, loff_t pos, unsigned len, @@ -3941,6 +4067,7 @@ static const struct file_operations shmem_file_operations = { .splice_read = generic_file_splice_read, .splice_write = iter_file_splice_write, .fallocate = shmem_fallocate, + .fadvise = shmem_fadvise, #endif };