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 82875C32771 for ; Wed, 28 Sep 2022 23:39:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9C2EE8D0002; Wed, 28 Sep 2022 19:39:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 94A648D0001; Wed, 28 Sep 2022 19:39:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7EAC38D0002; Wed, 28 Sep 2022 19:39:33 -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 6A0768D0001 for ; Wed, 28 Sep 2022 19:39:33 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2A55080FF8 for ; Wed, 28 Sep 2022 23:39:33 +0000 (UTC) X-FDA: 79963113426.27.1098BE6 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf23.hostedemail.com (Postfix) with ESMTP id 7BA04140008 for ; Wed, 28 Sep 2022 23:39:29 +0000 (UTC) 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664408372; 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=GtZBVoojZglRKf15s4Lbuh/hiw3mYqJL//9snIz2hts=; b=JhjzxJmKt3lDDsWwkiP5e/iEY+fzYxU7+ycHwjMbezuobFfxmF/Vic/ljbLURv7MNkqDIQ PEHU+MkGv7He6ejaGd+WLCalBFu/nIySJHc19IuD2y5A+4O0j8fQgL0SWCD/Z323ybfe8F XN2il6lQNkTHsSlB2Zp7EwI5ib1j1HM= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=qdJXfw9H; spf=none (imf23.hostedemail.com: domain of rdunlap@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=rdunlap@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664408372; a=rsa-sha256; cv=none; b=3eUjgi0TMq6lNoAV5gWuY1zkM2NhT1ll5lGDsuBJhGp4kpc0llYrMUnQvoj6awSaVcln2P RJPbHe1jli6Obowe52v0v15ao4DOh39WpRSqx4CBFfoK8/IfMxNAeRR8Yayl3mD4wYkkKn JasS2uW/OMHh7ok2NI1sne3ITKRG2Z8= Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=qdJXfw9H; spf=none (imf23.hostedemail.com: domain of rdunlap@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=rdunlap@infradead.org; dmarc=none X-Rspam-User: X-Stat-Signature: 9iwti87da1af7ewxjjkd9js3jdw11ufd X-Rspamd-Queue-Id: 7BA04140008 X-Rspamd-Server: rspam08 X-HE-Tag: 1664408369-314021 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-- 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