Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp1307168rwb; Wed, 28 Sep 2022 16:43:11 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6NSGYk0ReVJySRNWC6Mqlgc4Oqcr54wobYisGWv0Gl2bLAHho5hEzNBvHnmTvUU5R+u/zC X-Received: by 2002:a17:906:974d:b0:787:8884:9d with SMTP id o13-20020a170906974d00b007878884009dmr285542ejy.319.1664408591203; Wed, 28 Sep 2022 16:43:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664408591; cv=none; d=google.com; s=arc-20160816; b=XSyynXXatGWSSHsJHdWJcOWH+N8TNubK8z+tOOx1w22jcHrWpSBIl1eio+aTjdKVFY dYjMv4q9vcdORWdVo2ducZhaAvc4OBQhKQ5GiyBvx8P3yxswNtWvtq+tQHTHK1La3bCB 6r2tfgAQWDVYPpzv2C5sbaD1LyJwY3NGRngkI8ylH83hPUx1zGuRG3vOSWPt5sORwLhp ioqtnLAer0OUIL1lFJF7PiLf/DtiPjJjKVyUtHROEIcx/lcqoiT35EmKD9RO6MmM3PN7 bPNUUMQuUsxj/GJnDQDVpL3IZNfOaBVfmLEdnW1kE+XZkt3+rFVFjAsJW/9xS5BiriKK uDHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=GtZBVoojZglRKf15s4Lbuh/hiw3mYqJL//9snIz2hts=; b=IkJavGpGRq0/uHaoNg2Yvcob+6pn4MhCnEL3UF0OGhriEbXn8/JDYX9BYC0HbAuW+d 35T2/y4hbYEbw5GOO2tbxqay+/L6QNIyJmxyXGjb80m9XnznA43exIBNsODI6suVKdBJ 5v1fL6slRiC7bEEYChVYcswgwNGaXlLoNgfPJ0Z5zczdM0W59N7Qp8gTu7yfCNQr+cBd K6szT6i6GxHIzCMXMYsYpkNJZrsFZpPlPyUkcNjjF87KmctXizBHZowLYqTPOeLl29HL XV2HiIzICHdXJ5+eU0oZONw+cBDqMg0hy1jcznErPn4ZjI4M62/6HTEr9jVU/uW7+UDZ swTQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=qdJXfw9H; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sy26-20020a1709076f1a00b0072b0f6f1456si5586545ejc.612.2022.09.28.16.42.45; Wed, 28 Sep 2022 16:43:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=qdJXfw9H; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233904AbiI1Xkf (ORCPT + 99 others); Wed, 28 Sep 2022 19:40:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39716 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233803AbiI1XkJ (ORCPT ); Wed, 28 Sep 2022 19:40:09 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1EDA411DFE5; Wed, 28 Sep 2022 16:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Sender:Reply-To:Content-ID:Content-Description; bh=GtZBVoojZglRKf15s4Lbuh/hiw3mYqJL//9snIz2hts=; b=qdJXfw9HLJYQm7iBXKg1buwUGM 6U60rkI6EecBHtwAihCIasRxlVYvmfrnxjNivPY8DM9uiDvgb7cOj9HdbKAraknS15wN6Zc3wYS7Z Lwp520IWLcQc1wBL2bfl65cuG3M3GgjSiqM1qb3clItiuAqwmXpAXUhS7G16REb0GYGCVuZM6YVZW mUJgV1wb7y4WdbMz1eQPEBBeqhmHkOkXbuwvIXxGckwjlysE369nBXL53t+64zsK1CvSuaEHOkFvQ RXj36Fcnw26ulGFrlZ9zM+XVmkLj8Md1F8m713xWj55sQF7R3O3KuxQBJfIwy2DS+t9R48a/Xhzaf 1Dfrzo6g==; Received: from [2601:1c2:d80:3110::a2e7] by bombadil.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1odgeA-000fNc-1j; Wed, 28 Sep 2022 23:39:22 +0000 Message-ID: <574f63b0-5d34-617b-2b9d-b3b282fafd9e@infradead.org> Date: Wed, 28 Sep 2022 16:39:21 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [External] Re: [RFC] proc: Add a new isolated /proc/pid/mempolicy type. Content-Language: en-US To: Michal Hocko , Zhongkun He Cc: corbet@lwn.net, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, wuyun.abel@bytedance.com References: <20220926091033.340-1-hezhongkun.hzk@bytedance.com> <24b20953-eca9-eef7-8e60-301080a17d2d@bytedance.com> From: Randy Dunlap In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE,URIBL_SBL_A autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi-- On 9/26/22 07:08, Michal Hocko wrote: > On Mon 26-09-22 20:53:19, Zhongkun He wrote: >>> [Cc linux-api - please do so for any patches making/updating >>> kernel<->user interfaces] >>> >>> >>> On Mon 26-09-22 17:10:33, hezhongkun wrote: >>>> From: Zhongkun He >>>> >>>> /proc/pid/mempolicy can be used to check and adjust the userspace task's >>>> mempolicy dynamically.In many case, the application and the control plane >>>> are two separate systems. When the application is created, it doesn't know >>>> how to use memory, and it doesn't care. The control plane will decide the >>>> memory usage policy based on different reasons.In that case, we can >>>> dynamically adjust the mempolicy using /proc/pid/mempolicy interface. >>> >>> Is there any reason to make it procfs interface rather than pidfd one? >> >> Hi michal, thanks for your reply. >> >> I just think that it is easy to display and adjust the mempolicy using >> procfs. But it may not be suitable, I will send a pidfd_set_mempolicy patch >> later. > > proc interface has many usability issues. That is why pidfd has been > introduced. So I would rather go with the pidfd interface than repeating > old proc API mistakes. Sorry, I'm not familiar with the pidfd interface and I can't find any documentation on it. Is there some? Can I 'cat' or 'grep' in the pidfd interface? >> Btw.in order to add per-thread-group mempolicy, is it possible to add >> mempolicy in mm_struct? > > I dunno. This would make the mempolicy interface even more confusing. > Per mm behavior makes a lot of sense but we already do have per-thread > semantic so I would stick to it rather than introducing a new semantic. > > Why is this really important? Thanks. -- ~Randy