From mboxrd@z Thu Jan 1 00:00:00 1970 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 C727AC35274 for ; Thu, 21 Dec 2023 20:41:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4CE076B00B5; Thu, 21 Dec 2023 15:41:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 47E456B00B6; Thu, 21 Dec 2023 15:41:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 345376B00B7; Thu, 21 Dec 2023 15:41:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 25BE96B00B5 for ; Thu, 21 Dec 2023 15:41:30 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id EEA001A04B8 for ; Thu, 21 Dec 2023 20:41:29 +0000 (UTC) X-FDA: 81591995898.11.E3EF174 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by imf07.hostedemail.com (Postfix) with ESMTP id 2C64840006 for ; Thu, 21 Dec 2023 20:41:27 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ejEYn5DE; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of zokeefe@google.com designates 209.85.128.52 as permitted sender) smtp.mailfrom=zokeefe@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1703191288; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=IYDQWIBbPm5turhNZ7WI9Kit/Q3/OUHfzKGNIM8I7d4=; b=rxYWOXymPB/6PaCitej9SfptY7Sw8SsG8f4M0ndYHDE+P8sSFwBgynWBlkIS2N+FLOpmLE vw2ksWquNm6InzS86ik9uTHDPp6BrOZecMXw5ltRkPUhCctGnQeSR+G8h7JG6b+Vce+bLe B/yi1s1z9WI+VzL4RfMPsu3Nr5RzB3I= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ejEYn5DE; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of zokeefe@google.com designates 209.85.128.52 as permitted sender) smtp.mailfrom=zokeefe@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1703191288; a=rsa-sha256; cv=none; b=DIt9tSegW1KCLnUqYEO20Ggja3wcl4QzRF9bf/0bbYJy/AAMCnY/cxaneRxbJt2SEpB3Q0 /8U+Q8iySWXMxet0JontP93/aqIarygaSocoGqoJPtpnKbosS/o9Dl6eqRajIza3rIaOyC 4OIrMy5YTW48NSod63CWPYovnypX+Ek= Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-40c3963f9fcso1315e9.1 for ; Thu, 21 Dec 2023 12:41:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1703191286; x=1703796086; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=IYDQWIBbPm5turhNZ7WI9Kit/Q3/OUHfzKGNIM8I7d4=; b=ejEYn5DEUkb/eJQsmDTSAunlth/DwP2JNqmFw1SCdad5Z1pGMJ8cL+xcT2H4w/87r9 pK04wzuNF2ZqmmfGsAMvnT5Qkj7T+/u8TOzB3sxzJ0ht0G35LCKlQhunKgCCsYcennXD LiASqumD+9j6MwfQX18R1jtCn+d8Gig3yl56BDv7hdWOl/HLhb025JNShQ8mTSy2qAaB W7beC83sBMQugcp1zkagX2XdPrzGIWPtHj2+9SkaSVwvNLKnRoD24WRIPCJZaeNX5bRe N55rrav7E9k52d6Px0rkth2+1Ui2UbG2xiEag6vRbrSKOhs1RYKTgLaXc+E2aQnENn1P GnnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703191286; x=1703796086; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=IYDQWIBbPm5turhNZ7WI9Kit/Q3/OUHfzKGNIM8I7d4=; b=oddeieEIMS16fv0+FARgbDvPJYJcjVCNNfXJq5hda1jKdAo1TfW5lpmmwsL0+Ahfkv XBSFQ2z6anHOFhNstjH8a6/YysE8Efk0591CQK+ZWPZfy5jvw+H94W7ZIvsUZ6r5SE/3 rmxALJxlrqnysSYJb9jdcCQXQKiqf5TyU7kcHx2jVvDUgS3lH8/QqQ/bRza5vZPJKycl UuDAWrfE5hAHn6D6e9MTlyHbZlHTphTDINgr2OOGprAahIRsCRUW6zJYXJK+vT4ftSMV 67LpN5z1JjfGdHEZ7TpSFatXFOgyNXa21bwTL3jmw8KEB7QrAuXgXd43A73vJKQNqIe4 BuJA== X-Gm-Message-State: AOJu0YwRkg9Vs2mRlSJ/4BDBmn29nDJQI4+ajftTx16Y8Sa1JPVOZvtu ZTXVBvA/Mwbneu4ym75DpZpG/aCd+q2fripMp3pYcb/j17OU X-Google-Smtp-Source: AGHT+IE1oW6DEnHpdzQlHVFvhetFAQi8F3UjNl+32c58rfO+eJOX19iavSWAlT440q1GYcg1TZKjMU2CZlZk3zTV+D0= X-Received: by 2002:a05:600c:450e:b0:40d:2bc7:e9b with SMTP id t14-20020a05600c450e00b0040d2bc70e9bmr19340wmo.4.1703191286353; Thu, 21 Dec 2023 12:41:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Zach O'Keefe" Date: Thu, 21 Dec 2023 12:40:49 -0800 Message-ID: Subject: Re: [PATCH v3 0/2] attempt to map anonymous pte-mapped THPs by pmds To: Xu Yu Cc: linux-mm@kvack.org, david@redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 2C64840006 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: gmktdi8r9pxhs4n6bxpmnri63g9gzbqh X-HE-Tag: 1703191287-31221 X-HE-Meta: U2FsdGVkX19v8w7gCKriWxWNUo/MD44EeXt8MaJPyjbuINPwHpGwpmbZlIZwCfWMrnr2gCgxUbfBvbXjJsP0EwnWUlRhJ1TUBhmHAsP0rPOb5KZURetmJUSgzJjZHqXTHy6FGMFGeFyJDn4JHNF12//JsHsOuDYiTUHoBHo6cPeoXm5h5fSEkQWh/FVuR9C3eadQAPtov/j1s81Ao4hrbo8tm8gUEwR5kNcD7A9qfC0Xtwdi4M8fcUp/nPivvjWwGav7qpix7tY5TZf/chmQ+PMFA1cnxQ64Za1myiGE/ZvSSoshbwb8FyYwNZz51fUEpkQAheO5vO+v3CyBAd5tgW/f3lP16fKqoCdq74qhtkmdrr+wzlAD3Hwexg7LWcRpJQK5Xp77U+T3hPRLotylDLhYu3/t2rhwJBjOOwmB3oy0Gv31VYFtPDnIB9OIQ2vaTIBuYIKvEJI4TOe7T2qtUJj3nZP8Jt1v12jiUoEfM4axrD+wKmlaoERds7hkGYdSON6vEgszbkUS0GLpqaVKmCu0cQQ/ROOjEVFH2Xz3nMtF2Cvg7de8+K2T0gPQ3JTdpKlpraoZfb+mXx/IFFc7rbItKaq7xwIBI9Ge52M4ok5TMrbGpU5dW9Qwep/4Kg3wZzi0ye1n5a+OzVw8SVc3UIGVSy82/N407ybIas0NI89RWxQB98LcLYFCH1Tr869ZgDZIrciuD80SwU1xk4wr3sE3Hu0DbiwWxxqyfTLk3X2VU+Sh5FV4eLTxX/o4MxPUj8hLXDdd7kSvO+RV4tCxXEo7SHe98IN52Vt+VbVQPOxq/HtpWm8uaoMkpnTwwJt9md8h1r8nlp5hmlSeWuGWaQXxRhN+hnV8GRFwOWO9OyoUFqNDFtYfyLdW7YJXo7DXIFZHRhe/yoHCXLFf6kzbQa+Sc3LJcBi0x9Mux0NoKNT8Ve2JBwNcHBxFQRLOAHIzF9Yad14cQU24Zo5NrZ3 rkufxgr4 zEkLasjUuixipNqKqkO0RzuxODKZ9C/JYKslhOvNtzJ1oqDxfzSDNdQ3FIkMtuzQCUf0Bi90DocGWc6csp3IgZUPJ4jO5OeWn4K7USs4VW/klLEWiitF44lv6Qa83TBlglFCHOhz26cD9dWNigEK9xt2gH7bkcYO8VquNci97LinFSRVNiWB0W97awWpG2rKsl+0wexKGGgzfk3nWaYHKQbyU0C839RSxjN4XsmdPssp4sz7LI8ciVwF7mw== 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: List-Subscribe: List-Unsubscribe: Hey Xu, Thanks for the patches. As a precursor, can you help understand what the use case is for these patches? In-place collapse of anon memory is something I've thought about before, but the opportunity has never been especially clear. In particular, your patches take an order-9 compound page, and just try to see if we can update the mappings to it (like we do with file/shmem). Functionally this seems fine, but the difference is that with file/shmem, it's quite easy to have a pte-mapped-hugepage arise naturally (the formation of the hugepage happening in the pagecache being logically separate from the pmd-mapping of w/e task is mapping it).\ For anonymous memory, the only time I can see us having a pte-mapped hugepage (that isn't destined for splitting on deferred split list) that we want to remap by a pmd is if we cause a VMA split + remerge by mucking with VMA attributes. In my mind, what I had been thinking of w.r.t in-place anon collapse was for the case where we've split a THP with MADV_FREE/MADV_DONTNEED (i.e. to subrelease pages back to kernel), but later want to reform the THP. In particular, if, for example, we only subrelease O(10s) of order-0 pages, it seems wasteful to have to reallocate a fresh hugepage, then copy over O(100s) of pages, on collapse. If we were able to attempt to first migrate-away any of those previously subreleased pages (now possibly backing some other memory entirely), it could save us from having to allocate a fresh order-9 page. Under memory pressure / fragmentation, this could mean the difference between success and failure. Thanks for your help here, Zach On Sun, Dec 17, 2023 at 11:06=E2=80=AFPM Xu Yu wro= te: > > Result of tools/testing/selftests/mm/cow.c tests: > # [RUN] Basic COW after fork() when collapsing before fork() > ok 145 No leak from parent into child > # [RUN] Basic COW after fork() when collapsing after fork() (fully shared= ) > ok 146 No leak from parent into child > # [RUN] Basic COW after fork() when collapsing after fork() (lower shared= ) > ok 147 No leak from parent into child > # [RUN] Basic COW after fork() when collapsing after fork() (upper shared= ) > ok 148 No leak from parent into child > > A long run (w/ CONFIG_DEBUG_VM enabled) shows no panic or memory leaks. > > Changes since v2: > - Use folios in the new code, as suggested by David. > - Handle folio refcount and rmap properly, as suggested by David. > - minor modification includes 1) advance vma write lock, 2) remove > redundant rollback logic, 3) clear old ptes in pgtable before deposit. > > Changes since v1: > - Deal with PageAnonExclusive properly, as suggested by David. > > Xu Yu (2): > mm/khugepaged: map RO non-exclusive pte-mapped anon THPs by pmds > mm/khugepaged: map exclusive anonymous pte-mapped THPs by pmds > > mm/khugepaged.c | 229 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 229 insertions(+) > > -- > 2.37.1 > >