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 A1E43C54EE9 for ; Tue, 27 Sep 2022 13:07:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0EBAB8E00D2; Tue, 27 Sep 2022 09:07:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 09CBA8E00C1; Tue, 27 Sep 2022 09:07:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E7F2B8E00D2; Tue, 27 Sep 2022 09:07:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id D56948E00C1 for ; Tue, 27 Sep 2022 09:07:10 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 8F4C414014E for ; Tue, 27 Sep 2022 13:07:10 +0000 (UTC) X-FDA: 79957891020.12.5C16001 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) by imf12.hostedemail.com (Postfix) with ESMTP id 258B740003 for ; Tue, 27 Sep 2022 13:07:08 +0000 (UTC) Received: by mail-pl1-f180.google.com with SMTP id n7so289390plp.1 for ; Tue, 27 Sep 2022 06:07:08 -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 :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date; bh=wLWYmfFySAd0GACOj4/rphI/57VoRcvb+5EekgbbspY=; b=vpZuuu+cF8tKQW52wVI/FmSsjrI369ARx9x3l38QFDVBOY19iVxTCIFY2z5Z/RDz3c /KqBkQMe4HZvIYPfm/Q4Fj2R0q1L+Y6n3yo9mpWc/7QINyfciOuJ+CEbUu90eoA8MsvO wLL1YBsaHOMLuSkbDqCbZ9yRM0epZd8t+yVGMB3d8hKZuPMjQJ+ZfC32vFaybi9/L+Qe Dkpf6LxbuzCH8EAmobz/VVimGkbsUIwtpxwKTeXhIW6f5qb14YamDSOJ9PS+hG7NAuW2 KNnSDh8AQ2ixJUAHn2Q/qJKMWDQkFBR147zZRAozzgYpU11id1HWzvLMCBtWMRFKVnD3 bwXA== 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 :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=wLWYmfFySAd0GACOj4/rphI/57VoRcvb+5EekgbbspY=; b=HXzvRew4WMqH983Ke0XB8gqyJpJdXQG5XWxRu27+FEcMISqQdNZihqE2kmULNuC6yF kzLnxj0gewM/aM5ApM2mrUSRYWjSVZ45M6n5PhNFh9LBZBFxG0ftCVf833u5IG/RjsRn d7rbkW9lH1c5X7DvWZOduPQnA7P4/0H0YswJGYGk80VIQx0g11E7zoNQNygKC5pBcJ7x +iiBRSMg95ozEqJflL8A6XFyFbJKVKG1KgwMOacLMx2yzNjM3ybMoQexkoh1ygwnMhX5 CTZmVKOMGDd0mw0LFkpr9IDSq6UcjHsEoSAiKOojM/7c0uewymHl7xRxjYJf2JZhDvSG M3fQ== X-Gm-Message-State: ACrzQf3bYRSJ+5C8gON+6eBrBf9cBbJGXKdqaCISyv9O+CIarjK/DpwW TR3O1fIInmzO4ewi+amVcn3Neg== X-Google-Smtp-Source: AMsMyM7ruRMzAu8IGLLKYxSovEqEH/m8RWT1TTaVupSf2kDnDsYqaynyezwuWSmpP6dyNWjHeKLljA== X-Received: by 2002:a17:902:e841:b0:177:82b6:e6f7 with SMTP id t1-20020a170902e84100b0017782b6e6f7mr27664517plg.66.1664284027853; Tue, 27 Sep 2022 06:07:07 -0700 (PDT) Received: from [10.255.19.83] ([139.177.225.224]) by smtp.gmail.com with ESMTPSA id f22-20020a63f116000000b0042a713dd68csm1515083pgi.53.2022.09.27.06.07.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Sep 2022 06:07:07 -0700 (PDT) Message-ID: <9a0130ce-6528-6652-5a8e-3612c5de2d96@bytedance.com> Date: Tue, 27 Sep 2022 21:07:02 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Subject: Re: [External] Re: [RFC] proc: Add a new isolated /proc/pid/mempolicy type. Content-Language: en-US To: Michal Hocko Cc: Zhongkun He , corbet@lwn.net, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org References: <20220926091033.340-1-hezhongkun.hzk@bytedance.com> <24b20953-eca9-eef7-8e60-301080a17d2d@bytedance.com> <7ac9abce-4458-982b-6c04-f9569a78c0da@bytedance.com> From: Abel Wu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664284030; 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=wLWYmfFySAd0GACOj4/rphI/57VoRcvb+5EekgbbspY=; b=xHxkXMT0S6RRaALP49+eHhxPKZYc1VzTKeRAr9I2Ks1tQ06A94KOLkgk/tzJWSAVafcT16 090TF04MyWFMHLvqJYmnuB0UdPuZhoJED70h+ZZMMIc+liCLuwK2wD75C7HBIjmxnP4PMH 1smgjCVTQThmJsyeapGXLzSxRiR8k6c= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=vpZuuu+c; spf=pass (imf12.hostedemail.com: domain of wuyun.abel@bytedance.com designates 209.85.214.180 as permitted sender) smtp.mailfrom=wuyun.abel@bytedance.com; dmarc=pass (policy=none) header.from=bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664284030; a=rsa-sha256; cv=none; b=gfGk1D7u5psU8bmaS3SUiLWBbq9oE9+zQTfR5jMilPtU7Sp7w5ffrbUwH6+QFOY3rsHnjk SzG9nkthO28RsLoWA0DgdHkMQTlWXuwSymSw26idsrD3+0sHIcV9k5kTIx/yDFJuQjDW9z iGWtvxoy7lyeP35IyykMQo///DvpvRU= X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 258B740003 Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=vpZuuu+c; spf=pass (imf12.hostedemail.com: domain of wuyun.abel@bytedance.com designates 209.85.214.180 as permitted sender) smtp.mailfrom=wuyun.abel@bytedance.com; dmarc=pass (policy=none) header.from=bytedance.com X-Stat-Signature: wnogyhs1fkos3qepghri9ubdk9h4ri8a X-Rspam-User: X-HE-Tag: 1664284028-733884 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: On 9/27/22 6:49 PM, Michal Hocko wrote: > On Tue 27-09-22 11:20:54, Abel Wu wrote: > [...] >>>> 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? >> >> We want soft control on memory footprint of background jobs by applying >> NUMA preferences when necessary, so the impact on different NUMA nodes >> can be managed to some extent. These NUMA preferences are given by the >> control panel, and it might not be suitable to overwrite the tasks with >> specific memory policies already (or vice versa). > > Maybe the answer is somehow implicit but I do not really see any > argument for the per thread-group semantic here. In other words why a > new interface has to cover more than the local [sg]et_mempolicy? > I can see convenience as one potential argument. Also if there is a > requirement to change the policy in atomic way then this would require a > single syscall. Convenience is not our major concern. A well-tuned workload can have specific memory policies for different tasks/vmas in one process, and this can be achieved by set_mempolicy()/mbind() respectively. While other workloads are not, they don't care where the memory residents, so the impact they brought on the co-located workloads might vary in different NUMA nodes. The control panel, which has a full knowledge of workload profiling, may want to interfere the behavior of the non-mempolicied processes by giving them NUMA preferences, to better serve the co-located jobs. So in this scenario, a process's memory policy can be assigned by two objects dynamically: a) the process itself, through set_mempolicy()/mbind() b) the control panel, but API is not available right now Considering the two policies should not fight each other, it sounds reasonable to introduce a new syscall to assign memory policy to a process through struct mm_struct.