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 60554C4332F for ; Thu, 13 Oct 2022 12:51:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B7C716B0071; Thu, 13 Oct 2022 08:51:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B052F6B0073; Thu, 13 Oct 2022 08:51:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 957A88E0001; Thu, 13 Oct 2022 08:51:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 8024C6B0071 for ; Thu, 13 Oct 2022 08:51:07 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 457D1ABE97 for ; Thu, 13 Oct 2022 12:51:07 +0000 (UTC) X-FDA: 80015911374.30.40EAD79 Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com [209.85.217.54]) by imf13.hostedemail.com (Postfix) with ESMTP id EF39820034 for ; Thu, 13 Oct 2022 12:51:05 +0000 (UTC) Received: by mail-vs1-f54.google.com with SMTP id 3so1636113vsh.5 for ; Thu, 13 Oct 2022 05:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=E2cH3XkUWNLmNpwPQYLhtWACtStFj+VXNiGHkNXCbo0=; b=XxwCvmQ1OfqgGGbTHrcRTCqJQWsDbCAQaVv1lDeA+U/bZDTMcdIsls3Z9siap5rSd2 hvneGkBQHEedy2YDOcb9hXvo33bTwqgMS5dmPvBRasi2lr/hp7IeptFLeUIqjRU0lFTI uizc1YvsBhmHDhetspqPlCknQqP4Y3kZs9h5lfpRI3voVtOcm2ljtlxXREaNF+6Hcny6 v5tVRgHfAhPBy4SrwxfCP0wHcZ1F1lev3ymv1oSe0Q4+FAFq1GJS/oLSrrFxEDRoepS+ 3rCqFR/1Y3jQ7FGzes2cKVlq5c8J6p84PORSkId4LuLMZV3rR1Rnsagi/dMrZj/dHMcx UPbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=E2cH3XkUWNLmNpwPQYLhtWACtStFj+VXNiGHkNXCbo0=; b=54MMnvjFRRMPMVfx4MvBWU6bchWjY7teEXcM88VpQ8RLigBaMNQukaT309K4ecDGMX IPu9jF11Xglq2ovRbrr2s7L8TYtqgSw+gMFGjwwL7rR845REHV1QG8x0/0/12nXTiYug Prf6ZEHSCydwuR2XLzL+deYtr+JBy5pJ1OdTSxnBki0t8XoGuE4X/bSm6Ft7OhEYpKoi 7IPI+h1ZJ+7srF/k31H//NWoPU135r/3Ve/nT/IHD+sJvUSdZcJrElDu3PUyiZ3+xCPT niaHXcmyl6TCOWh6qcKY74M8MkeTrhdY04zEq21mJh+Z/JW+TEUMrcqEzvmMSyi57JKo 0JOA== X-Gm-Message-State: ACrzQf0oxHspQ+4D89QQyyTKdSL3yfPTrgZRKmbc8yoME8ziSmrRrgam MbY1NAqB3Uy2REeg+FQdicJKxSGQMdTz2w== X-Google-Smtp-Source: AMsMyM5wWXDn76e8mvrqcBBxuxQMpTsIi+Sda1mv26vttJb13vgAl0Xcx57FAQYYbgMIO1+VqhQeeQ== X-Received: by 2002:a17:902:da8a:b0:180:6f4f:beee with SMTP id j10-20020a170902da8a00b001806f4fbeeemr30972033plx.82.1665665454343; Thu, 13 Oct 2022 05:50:54 -0700 (PDT) Received: from [10.68.76.92] ([139.177.225.245]) by smtp.gmail.com with ESMTPSA id c72-20020a621c4b000000b00561c179e17dsm1934281pfc.76.2022.10.13.05.50.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Oct 2022 05:50:53 -0700 (PDT) Message-ID: Date: Thu, 13 Oct 2022 20:50:48 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.2 Subject: Re: [External] Re: [RFC] mm: add new syscall pidfd_set_mempolicy() To: Michal Hocko Cc: corbet@lwn.net, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, wuyun.abel@bytedance.com References: <20221010094842.4123037-1-hezhongkun.hzk@bytedance.com> <582cf257-bc0d-c96e-e72e-9164cff4fce1@bytedance.com> From: Zhongkun He In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=XxwCvmQ1; spf=pass (imf13.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.217.54 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com; dmarc=pass (policy=none) header.from=bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665665466; a=rsa-sha256; cv=none; b=yaOzJLOG8+XCOQXaN1FmoHI7qpu1QTSAmOW+lf7XKbsAGgRiu5McHvXPca7tu5ipEAqcuP iE32uPw0bPldwdlDHkKtCe0+FZeqSAtyXBQtmboGaeqRjW2y29FX7IEHLoocpWfx1Ka+en boeWYfaNxJrNZUmXmd6htqk3K4CEtc0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665665466; 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=E2cH3XkUWNLmNpwPQYLhtWACtStFj+VXNiGHkNXCbo0=; b=ufX+lp95OUDQV9neGki9qvJUW+/HZK9YoKcxDy/T/kgnc+q3e6btA89Jz3k3juicSmzkVD Z8Qdi+H+Cb70gF1I5vXilZxwf5ZK75m1nVHLXjj6g3iu4o7Ged+C7ZoBCycd1PRZt1ZXk5 CjGAFM7S6EIE0lnySiCjDz6FgiMhQjE= X-Rspam-User: Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=XxwCvmQ1; spf=pass (imf13.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.217.54 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com; dmarc=pass (policy=none) header.from=bytedance.com X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: EF39820034 X-Stat-Signature: rdhzsooo69z3ji7h8yy4cwmkbtodr8kh X-HE-Tag: 1665665465-485735 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: >> Hi Michal >> >> Could we try to change the MPOL_F_SHARED flag to MPOL_F_STATIC to >> mark static mempolicy which cannot be freed, and mpol_needs_cond_ref >> can use MPOL_F_STATIC to avoid freeing the static mempolicy. > > Wouldn't it make more sense to get rid of a different treatment and > treat all memory policies the same way? I found a case, not sure if it makes sense. If there is no policy in task->mempolicy, the use of atomic_{inc,dec} can be skiped according to MPOL_F_STATIC. Atomic_{inc,dec} in hot path may reduces performance. Thanks.