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 7AFBEC433EF for ; Fri, 3 Jun 2022 13:33:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B30F68D0002; Fri, 3 Jun 2022 09:33:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ADB058D0001; Fri, 3 Jun 2022 09:33:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9CBC68D0002; Fri, 3 Jun 2022 09:33:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 8CDBA8D0001 for ; Fri, 3 Jun 2022 09:33:41 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 5745634DDC for ; Fri, 3 Jun 2022 13:33:41 +0000 (UTC) X-FDA: 79537017042.21.A299960 Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) by imf03.hostedemail.com (Postfix) with ESMTP id 5C84120013 for ; Fri, 3 Jun 2022 13:33:25 +0000 (UTC) Received: by mail-lf1-f46.google.com with SMTP id be31so12634039lfb.10 for ; Fri, 03 Jun 2022 06:33:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qTnWb0i8HF7w6+9QffhBR/POtrIX+5rsxlUnNIzutTY=; b=dFdVrqI4ipX2WCY9AA7qlT3yYMT6qxDSJKXaBpU38HHm6WDoXXMI2JuP8S8PugkPpe qqGjGMHZ+xbTiwmvUoqQVDExuCRZPoslpqbotKVwI1L7REDFVmP1fG7e8GQBvoXsTuPk 80+oENQMX1CD7/4A4RAr+H3BAH7V4Oz46qoUk099NMQxh/0o5FPDLwIGrGSFB1DW9ECF yF1VoZKWuu1YEF2Wf8iMJurcH2fKNziChcT/6h7THNAUTxP99wjcEfG4Hl0nVLdGT0zz 4DaNJRnlAXALDMfULYA42UpS2YchDw46Y66No8EKioGzvTKG7hMCJ+Sb+pZtyAS/u86Z H8sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qTnWb0i8HF7w6+9QffhBR/POtrIX+5rsxlUnNIzutTY=; b=at0XIY9DQImnQL3BLeA9vygMkUZW4wojRnun2Q/R7RUCvC17ieMKxeoVdW31AtKYIC Q1nUVueSNnBYfsVcn6y7n9w4RSgk1mNjVL1sN31bcpqmEZZ74b1BU3cA8QMEZU1vgl1y wqqO7n0tPxx5sKCj8KwQqPoRiI9C53cPanZrvHaHJ4tJfyANJJkaxDW6J00dFsdjaZ5o RFa/XV1TmdgbIMK8r11pUXPBXvhUwzuH/aqMwGz8e2Zid8gql4WgZQnyQCpq2jUk68Ap SUvnn9voFQCZOcQB4qziI5DDNDqQ8A82cs6wbguSlIP8VW90qnea0aRM0wjEKECJfxvW hvgQ== X-Gm-Message-State: AOAM533Pp9oQVwHLrMuZEWtN0AgQj9k7u25kA09r8e3hbUMgJ1/aGkkW rkIe0V6+HjUfry5AhRJl8bsJzA/qPpFwFkp4OlOLTQ== X-Google-Smtp-Source: ABdhPJxAW0XLU+xxW6hQjd6P9LTzWP1P1pUCTsMdDNXDuVZlgvLo0cF4H1Jq0FASZ4teQ3kMT8IzvlDB3iWTGAoODYA= X-Received: by 2002:a05:6512:249:b0:479:a3c:de with SMTP id b9-20020a056512024900b004790a3c00demr7040439lfo.128.1654263219090; Fri, 03 Jun 2022 06:33:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Zach O'Keefe" Date: Fri, 3 Jun 2022 06:33:02 -0700 Message-ID: Subject: Re: [RFC] mm: MADV_COLLAPSE semantics To: David Hildenbrand , David Rientjes , Matthew Wilcox , Michal Hocko , Peter Xu , linux-mm@kvack.org, rongwei.wang@linux.alibaba.com, Yang Shi Cc: Alex Shi , Song Liu , Andrea Arcangeli , Axel Rasmussen , Hugh Dickins , "Kirill A. Shutemov" , Minchan Kim , SeongJae Park , Pasha Tatashin Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: 16dfu5kemmxpd5sjhgmgqufzq756gmej Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=dFdVrqI4; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of zokeefe@google.com designates 209.85.167.46 as permitted sender) smtp.mailfrom=zokeefe@google.com X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 5C84120013 X-HE-Tag: 1654263205-132993 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: Ok, I think I'll wrap up this thread. Again, thanks all for taking the time to voice their thoughts and have this great discussion. As Yang suggested, I'll start by proposing MADV_COLLAPSE isn't tied to any of the THP sysfs knobs and we'll see if there are any additional issues / concerns raised. Thanks again for everyone's time! Best, Zach On Fri, Jun 3, 2022 at 6:26 AM Zach O'Keefe wrote: > > On Thu, Jun 2, 2022 at 9:43 AM Yang Shi wrote: > > > > On Wed, Jun 1, 2022 at 11:56 PM Michal Hocko wrote: > > > > > > On Wed 01-06-22 10:25:53, Yang Shi wrote: > > > > On Wed, Jun 1, 2022 at 2:50 AM Michal Hocko wrote: > > > > > > > > > > On Tue 31-05-22 16:47:49, Yang Shi wrote: > > > > > > On Fri, May 27, 2022 at 2:46 AM Michal Hocko wrote: > > > > > [...] > > > > > > > I really do not see any good reason to tightly couple kernel and user > > > > > > > policies. Hints like MADV_{NO}HUGEPAGE are one thing and both kernel > > > > > > > and userspace might decide to interpret them. But binding MADV_COLLAPSE > > > > > > > to in kernel THP tunables just seems like pushing ourselves into the > > > > > > > corner. > > > > > > > > > > > > I don't mean we should tightly couple kernel and user policies. I > > > > > > think it is about how "never" is treated. AFAICT, typically sys admins > > > > > > tend to expect "never" as a global switch and they don't expect any > > > > > > THP allocation should happen in "never" mode even though it is > > > > > > requested by the users. Maybe they should not expect so in the first > > > > > > place. > > > > > > > > > > But this is not how the knob works, right? At least shmem has its own > > > > > thing. So we do not have any global kill switch for transparent huge > > > > > pages. > > > > > > > > Yeah, but shmem has "never" mode too, which has the same semantics and > > > > it is the default mode actually. Since MADV_COLLAPSE just collapse > > > > anon memory for now, so the discussion was focused on anon THP. But > > > > shmem is same. > > > > > > Do you expect MADV_COLLAPSE would stick to the anonymous memory? Are we > > > going to get MADV_COLLAPSE_SHMEM, MADV_COLLAPSE_FOR_REAL? > > > > No, my point is "never" mode has the same semantics for both anon and > > shmem. When we were talking about whether MADV_COLLAPSE should respect > > "never" or not, it means both. > > Ya, this is a good point, and something I honestly overlooked > originally when posting this thread. > > > > > > > -- > > > Michal Hocko > > > SUSE Labs