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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 46D51C433E0 for ; Thu, 4 Mar 2021 10:52:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A3F4664F31 for ; Thu, 4 Mar 2021 10:52:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A3F4664F31 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E75F76B0005; Thu, 4 Mar 2021 05:52:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DFDF76B0006; Thu, 4 Mar 2021 05:52:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C789A6B0007; Thu, 4 Mar 2021 05:52:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0213.hostedemail.com [216.40.44.213]) by kanga.kvack.org (Postfix) with ESMTP id A67C36B0005 for ; Thu, 4 Mar 2021 05:52:32 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 5723D180D8725 for ; Thu, 4 Mar 2021 10:52:32 +0000 (UTC) X-FDA: 77881878144.22.3962F23 Received: from out30-43.freemail.mail.aliyun.com (out30-43.freemail.mail.aliyun.com [115.124.30.43]) by imf16.hostedemail.com (Postfix) with ESMTP id 8CAD680192E8 for ; Thu, 4 Mar 2021 10:52:29 +0000 (UTC) X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R581e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04395;MF=alex.shi@linux.alibaba.com;NM=1;PH=DS;RN=13;SR=0;TI=SMTPD_---0UQPRg.5_1614855144; Received: from IT-FVFX43SYHV2H.local(mailfrom:alex.shi@linux.alibaba.com fp:SMTPD_---0UQPRg.5_1614855144) by smtp.aliyun-inc.com(127.0.0.1); Thu, 04 Mar 2021 18:52:25 +0800 Subject: Re: [RFC] Hugepage collapse in process context To: David Rientjes Cc: David Hildenbrand , Vlastimil Babka , Michal Hocko , Hugh Dickins , Andrea Arcangeli , "Kirill A. Shutemov" , Song Liu , Matthew Wilcox , Minchan Kim , Chris Kennelly , linux-mm@kvack.org, linux-api@vger.kernel.org References: <0b51a213-650e-7801-b6ed-9545466c15db@suse.cz> <600ee57f-d839-d402-fb0f-e9f350114dce@redhat.com> <5127b9c-a147-8ef5-c942-ae8c755413d0@google.com> <25d9347b-9359-efab-e1e3-f98bd0012af9@linux.alibaba.com> <544df052-f9f3-f068-f69e-343cc69d994b@google.com> From: Alex Shi Message-ID: Date: Thu, 4 Mar 2021 18:52:24 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <544df052-f9f3-f068-f69e-343cc69d994b@google.com> Content-Type: text/plain; charset=gbk X-Stat-Signature: fep13ptam5kdy55fwrbef981rj1d331w X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 8CAD680192E8 Received-SPF: none (linux.alibaba.com>: No applicable sender policy available) receiver=imf16; identity=mailfrom; envelope-from=""; helo=out30-43.freemail.mail.aliyun.com; client-ip=115.124.30.43 X-HE-DKIM-Result: none/none X-HE-Tag: 1614855149-541010 Content-Transfer-Encoding: quoted-printable 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: =D4=DA 2021/3/2 =C9=CF=CE=E74:56, David Rientjes =D0=B4=B5=C0: > On Wed, 24 Feb 2021, Alex Shi wrote: >=20 >>> Agreed, and happy to see that there's a general consensus for the=20 >>> direction. Benefit of a new madvise mode is that it can be used for=20 >>> madvise() as well if you are interested in only a single range of you= r own=20 >>> memory and then it doesn't need to reconcile with any of the already=20 >>> overloaded semantics of MADV_HUGEPAGE. >> >> It's a good idea to let process deal with its own THP policy. >> but current applications will miss the benefit w/o changes, and change= is >> expensive for end users. So except this work, may a per memcg collapse= benefit >> apps and free for them, we often deploy apps in cgroups on server now. >> >=20 > Hi Alex, >=20 > I'm not sure that I understand: this MADV_COLLAPSE would be possible fo= r=20 > process_madvise() as well and by passing a vectored set of ranges so a=20 > process can do this on behalf of other processes (it's the only way tha= t=20 > we could theoretically move khugepaged to userspace, although that's no= t=20 > an explicit end goal). >=20 Forgive my stupidity, I still can't figure out how process_madvise caller fill the iovec of other's on a common system.=20 >=20 > How would you see this working with memcg involved? I had thought this= =20 > was entirely orthogonal to any cgroup. >=20 You'r right, it's out of cgroup and better. per cgroup khugepaged could b= e a alternative way. but it require a cgroup and not specific on target pro= cess. Thanks Alex =20