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 2401EC4332F for ; Wed, 12 Oct 2022 12:34:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 44B556B0071; Wed, 12 Oct 2022 08:34:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3FBF16B0073; Wed, 12 Oct 2022 08:34:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 29B36900002; Wed, 12 Oct 2022 08:34:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 123306B0071 for ; Wed, 12 Oct 2022 08:34:45 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id BDBCBA07FB for ; Wed, 12 Oct 2022 12:34:44 +0000 (UTC) X-FDA: 80012241288.01.218C798 Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) by imf15.hostedemail.com (Postfix) with ESMTP id 687B5A0028 for ; Wed, 12 Oct 2022 12:34:44 +0000 (UTC) Received: by mail-pj1-f48.google.com with SMTP id q10-20020a17090a304a00b0020b1d5f6975so1949293pjl.0 for ; Wed, 12 Oct 2022 05:34:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=NFBHoOeG3ghGeuO274+7fL8QgYjk7OYjm0X789Rsduk=; b=ea0YD8TEwyHxV2D0ffzgep/rqf+7nMi89namwACoS79RTxlEuwazEaupSaJqkcaIhP W5BWcaB16bI2AalWWeM36/ijmi76MRUFY7aE+d/m83LdlAGuSeOdwL8B2R/V3bBq09D9 /p9L55f7HaKlONLqq8N1ZWKJ1q0pPVZalzfB9xgVrbqqbJ2UP80VxhzsQBeZQH8MG8W7 tj9vvM6YOCEFNMOLHKTXyAPP2I/jI2I5CkkRJ2eiLYyAO9I1UCsDYvOEbPrH+obRCv6y yxfwjE9IZYrkCpzlbrZ5DKX6wqB79ZqyomP7C1u83f7ty7IfaFl692KGlOqQrxAxxL2x NZCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=NFBHoOeG3ghGeuO274+7fL8QgYjk7OYjm0X789Rsduk=; b=hg6X9PxwE/7dSKG44R7aqN1MyD5DrFrp5166k6zsEeaWFRc/Zj9OvaQWR3XgZTYTIO 0qh+QrSq5G9LdMKh0cH+M11MwYxGpqHnFdjeKvVe8y9iE8k1R01VqzH1GSknZ7sTsgiS xW7CTxNTy1PiFMgthpzzikvyAZ/qkUjM40XwPThqI802Po8q7UPacJanaIHEmhzg2QRR NzXvw/T2JOebQm4YViyJSsC9SYQvWzY/m3u/lD9buTB+PUoWZMnOzVjKc+nOU2kyg8lY jKXgl8aoeQam1a1v5/W6vzImv0Pr4nr35huwxGQ6um3D1jL+TY1bPJNWbhfeaFb0j1gZ 3x8g== X-Gm-Message-State: ACrzQf1/MQpZLMPmxeGiqPd+juq4eXuUyVF1OInNWbQG74vulswbrT/g 0k7Z/gGsFZf+BSbPkGwWAdlilFdPDcw899LAs/Y= X-Google-Smtp-Source: AMsMyM7vomdIe7mnxwPdFaZGIzuDJHCoALDasxWDvWlwqR7qabo9kulZv+0PAH7jr/hGViyB7QrdwnPv3s0QAACNN94= X-Received: by 2002:a17:90b:4a4d:b0:20d:4dc7:fa72 with SMTP id lb13-20020a17090b4a4d00b0020d4dc7fa72mr4814262pjb.86.1665578083191; Wed, 12 Oct 2022 05:34:43 -0700 (PDT) MIME-Version: 1.0 References: <20221010094842.4123037-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: Vinicius Petrucci Date: Wed, 12 Oct 2022 07:34:06 -0500 Message-ID: Subject: Re: [RFC] mm: add new syscall pidfd_set_mempolicy() To: Michal Hocko Cc: Frank van der Linden , Zhongkun He , 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 Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665578084; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=NFBHoOeG3ghGeuO274+7fL8QgYjk7OYjm0X789Rsduk=; b=NEQQfl7TliiOcV+QZTP5uCwizUyTewbruuHNMICKGkGMjZ8VMAmwng/gUAMmyFVSTTszr7 vMrsR2caft6QdcPsm7ZDF1hxvGVsMUxW3akf5awvF2ShPTolpo+R82lFyo1Vcul+XG1eI/ DEuCwTS0PGWW77Ze/TWVTWmE/h2Rnkk= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ea0YD8TE; spf=pass (imf15.hostedemail.com: domain of vpetrucci@gmail.com designates 209.85.216.48 as permitted sender) smtp.mailfrom=vpetrucci@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665578084; a=rsa-sha256; cv=none; b=M4a+P6JrbvxOQb4ut/M/EmJcc4eZAriHOJcDL9bpZVRC0Fgp0HkgE570TDkV6Lts7wru9R FjXyxM13qh7IRY8qgzhiB/AsnfshTBRgmGSZ2qeLNhvYTAVBJiecMsmzE4DypcTaBsz8VL ChAdOL4+NWm5MLUg6E184isyUi/NugU= X-Rspam-User: X-Rspamd-Server: rspam11 Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ea0YD8TE; spf=pass (imf15.hostedemail.com: domain of vpetrucci@gmail.com designates 209.85.216.48 as permitted sender) smtp.mailfrom=vpetrucci@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: z3sywkjjbto8ws1fmtnp6zstuttufoae X-Rspamd-Queue-Id: 687B5A0028 X-HE-Tag: 1665578084-541089 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: > Well, per address range operation is a completely different beast I > would say. External tool would need to a) understand what that range is > used for (e.g. stack/heap ranges, mmaped shared files like libraries or > private mappings) and b) by in sync with memory layout modifications > done by applications (e.g. that an mmap has been issued to back malloc > request). Quite a lot of understanding about the specific process. I > would say that with that intimate knowledge it is quite better to be > part of the process and do those changes from within of the process > itself. Sorry, this may be a digression, but just wanted to mention a particular use case from a project I recently collaborated on (to appear next month at IIWSC 2022: http://www.iiswc.org/iiswc2022/index.html). We carried out a performance analysis of the latest Linux AutoNUMA memory tiering on graph processing applications. We noticed that hot pages cannot be properly identified by the reactive approach used by AutoNUMA due to irregular/random memory access patterns. Thus, as a POC, we implemented and evaluated a simple idea of having an external user-level process/agent that, based on prior profiling results of memory regions, could make more effectively memory chunk/object-based mappings (instead of page-level allocation/migration) in advance on either DRAM or CXL/PMEM (via mbind calls). This kind of tiering solution could deliver up to 2x more performance for graph analytics workloads. We plan to evaluate other workloads as well. Having a feature like "pidfd/process_mbind" would really simplify our user-level agent implementation moving forward, as right now we are adding a LD_PRELOAD wrapper (for signal handler) to listen and execute "mbind" requests from another process. If there's any other alternative solution to this already (via ptrace?), please let me know. Thank you! Vinicius Petrucci Principal Performance Engineer Micron Technology