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 X-Spam-Level: X-Spam-Status: No, score=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E4944C433B4 for ; Wed, 5 May 2021 05:06:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2FC02611EE for ; Wed, 5 May 2021 05:06:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2FC02611EE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=bytedance.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8982A6B006C; Wed, 5 May 2021 01:06:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 847576B006E; Wed, 5 May 2021 01:06:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C1426B0070; Wed, 5 May 2021 01:06:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0002.hostedemail.com [216.40.44.2]) by kanga.kvack.org (Postfix) with ESMTP id 4D3226B006C for ; Wed, 5 May 2021 01:06:17 -0400 (EDT) Received: from smtpin40.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id F36FF180ACEFB for ; Wed, 5 May 2021 05:06:16 +0000 (UTC) X-FDA: 78105991152.40.B448405 Received: from mail-pg1-f173.google.com (mail-pg1-f173.google.com [209.85.215.173]) by imf20.hostedemail.com (Postfix) with ESMTP id 4BA8912E for ; Wed, 5 May 2021 05:06:08 +0000 (UTC) Received: by mail-pg1-f173.google.com with SMTP id c21so989566pgg.3 for ; Tue, 04 May 2021 22:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=7gpK7P2CpPVVCbVLUyVVTrI01QfMpCG4qxYH2m0q/WY=; b=hRMfiR1c8aF8nkaibSuLvPsQ8VyCx/qSncGkzxu18vorhQYjFwpROhAEbXYMCNfquk R79aCKblQiB16JvI81QOiFG7hoE+vwWFzuhbV1jcmU/QB6LmQwc8IoHRHHgrHKr1AooE osQlLpZYwvRJRTQEWQKzZE0vUJAkPSCwibEEASukSg4xW9ERGzKZ40/yoQH+95owSb6v iLEPDrI5blgVJviaQyBNxrHi4u/g5MffBYnIDhQOKoi0ygD8CMEeF9UCIMm87nzMRxHJ P8UUlfcrr05jevKCiccoYy4X4FyQ6RYZzLzqVTr8I8qEmKxi4cqZReJU1TEVcBJWusH4 /VZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7gpK7P2CpPVVCbVLUyVVTrI01QfMpCG4qxYH2m0q/WY=; b=sD2iYIFfdKEvKK50y6PEouCoJHPB24IY2gSfO5rz9JvHjr3h14urVvaC3Re3GdcNEa XV0TRqBW/2dVmgRTIpeZ/omD4eUvQXMjUKH9rJK6hqFHar/25oB7ovtxLWkw17FtapPw UDdGqsD0SLOQS+gY5dH0KzVpfulhJP9xB8zmad8LYeTxKYle9D/hwsH0afc7e/aO4OBh HLfwto0GGjd/sc4GfhczNAsBknB9VIGner5NYTw/gQnG4B2TBkzcqT1tS8/v5PWdVpyj ZNF+tdCROzjTocWS5fPDlob31E52OiRfofO109XeFiP/UcWmqjnoYiHPX2EojrOh2SMC JHqw== X-Gm-Message-State: AOAM531CZ423IuA9jZu07G3+udBSCcSDC7NgGma6+Z2WdXKSjbW2CcTL Qc+CMtuV7qR8fp0MMq6aOo0eTA== X-Google-Smtp-Source: ABdhPJz9VCC3PefBm33FrYikAk5yJSpijtIJiHa1jMrpQcN0eALeOoj+FqzHKiLwil2NOY6iXfaG3A== X-Received: by 2002:a62:ed0b:0:b029:25c:9ea2:abea with SMTP id u11-20020a62ed0b0000b029025c9ea2abeamr27332089pfh.46.1620191174556; Tue, 04 May 2021 22:06:14 -0700 (PDT) Received: from [10.254.93.79] ([139.177.225.238]) by smtp.gmail.com with ESMTPSA id k10sm13420308pff.140.2021.05.04.22.06.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 May 2021 22:06:14 -0700 (PDT) Subject: Re: [Phishing Risk] [External] Re: [PATCH 2/3] cgroup/cpuset: introduce cpuset.mems.migration To: Tejun Heo , hannes@cmpxchg.org Cc: akpm@linux-foundation.org, lizefan.x@bytedance.com, corbet@lwn.net, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org References: <20210426065946.40491-1-wuyun.abel@bytedance.com> <20210426065946.40491-3-wuyun.abel@bytedance.com> From: Abel Wu Message-ID: <55582805-5103-96c0-d8e8-e6d0b01beff3@bytedance.com> Date: Wed, 5 May 2021 13:06:09 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 4BA8912E X-Stat-Signature: codfhuh3o8ptwxihncsaukxpdwx91xn1 Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=bytedance-com.20150623.gappssmtp.com header.s=20150623 header.b=hRMfiR1c; spf=pass (imf20.hostedemail.com: domain of wuyun.abel@bytedance.com designates 209.85.215.173 as permitted sender) smtp.mailfrom=wuyun.abel@bytedance.com; dmarc=pass (policy=none) header.from=bytedance.com Received-SPF: none (bytedance.com>: No applicable sender policy available) receiver=imf20; identity=mailfrom; envelope-from=""; helo=mail-pg1-f173.google.com; client-ip=209.85.215.173 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620191168-486197 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: ping :) On 4/27/21 10:43 PM, Tejun Heo wrote: > Hello, >=20 > On Mon, Apr 26, 2021 at 02:59:45PM +0800, Abel Wu wrote: >> When a NUMA node is assigned to numa-service, the workload >> on that node needs to be moved away fast and complete. The >> main aspects we cared about on the eviction are as follows: >> >> a) it should complete soon enough so that numa-services >> won=E2=80=99t wait too long to hurt user experience >> b) the workloads to be evicted could have massive usage on >> memory, and migrating such amount of memory may lead to >> a sudden severe performance drop lasting tens of seconds >> that some certain workloads may not afford >> c) the impact of the eviction should be limited within the >> source and destination nodes >> d) cgroup interface is preferred >> >> So we come to a thought that: >> >> 1) fire up numa-services without waiting for memory migration >> 2) memory migration can be done asynchronously by using spare >> memory bandwidth >> >> AutoNUMA seems to be a solution, but its scope is global which >> violates c&d. And cpuset.memory_migrate performs in a synchronous >=20 > I don't think d) in itself is a valid requirement. How does it violate = c)? >=20 >> fashion which breaks a&b. So a mixture of them, the new cgroup2 >> interface cpuset.mems.migration, is introduced. >> >> The new cpuset.mems.migration supports three modes: >> >> - "none" mode, meaning migration disabled >> - "sync" mode, which is exactly the same as the cgroup v1 >> interface cpuset.memory_migrate >> - "lazy" mode, when walking through all the pages, unlike >> cpuset.memory_migrate, it only sets pages to protnone, >> and numa faults triggered by later touch will handle the >> movement. >=20 > cpuset is already involved in NUMA allocation but it always felt like > something bolted on - it's weird to have cpu to NUMA node settings at g= lobal > level and then to have possibly conflicting direct NUMA configuration v= ia > cpuset. My preference would be putting as much configuration as possibl= e on > the mm / autonuma side and let cpuset's node confinements further restr= ict > their operations rather than cpuset having its own set of policy > configurations. >=20 > Johannes, what are your thoughts? >=20 > Thanks. >=20