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 E230CC4707C for ; Thu, 11 Jan 2024 03:41:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 379C36B009C; Wed, 10 Jan 2024 22:41:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 329776B009D; Wed, 10 Jan 2024 22:41:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1CA756B009E; Wed, 10 Jan 2024 22:41:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 082596B009C for ; Wed, 10 Jan 2024 22:41:16 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D04A81C1309 for ; Thu, 11 Jan 2024 03:41:15 +0000 (UTC) X-FDA: 81665629710.17.A045B0F Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) by imf05.hostedemail.com (Postfix) with ESMTP id 621E3100008 for ; Thu, 11 Jan 2024 03:41:13 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=hAXKlOos; spf=none (imf05.hostedemail.com: domain of ak@linux.intel.com has no SPF policy when checking 198.175.65.13) smtp.mailfrom=ak@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704944474; a=rsa-sha256; cv=none; b=XRW4uJpvggLDXAvz29+xktbRXz9p0uPfv3VvMUy0UuosTwgyejrdiJo3hlB8sx/zRFfNr7 V+lcYUQTmKhKm0tkG/UmEbHj3XBwTyZ0231oaEM4Q4Aiw6O57Avi7Utl1pgNxKLhGVKc7C ZQAwd6V/iwuchBfv7wbmHXzstAo3gNg= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=hAXKlOos; spf=none (imf05.hostedemail.com: domain of ak@linux.intel.com has no SPF policy when checking 198.175.65.13) smtp.mailfrom=ak@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704944474; 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=VjA0CiBylOVxmWFMtQXuHeD1XQpmT0dBjjgIBgCaZ/Q=; b=yvz8bzhfgpW9qn5m3w0NBc7sVTCq6Xk9KXlxqwLLrSSTFCXFYoZ7SClVnpnw3pzG6F4PSG y4W0Xmk3urALSpk8GEtjI3ow7IuOZtURwFnA/QyCgvmSpvNwhm/DPWeQjEkHWrghcaF3qQ NoAidsQdaAs6W3AeTzE6yRi6foGl7ZY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1704944473; x=1736480473; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=VjA0CiBylOVxmWFMtQXuHeD1XQpmT0dBjjgIBgCaZ/Q=; b=hAXKlOoskyQj0IgmUTn4bPnDqGm7RJfzfmE+L470BnMp37459wkDesCi doN/lKdRPlgQ3fJ39opYdzbN57EfBJswB7GFVZ4qOnkkvnkFfyh5SPF97 Im6GTTatSCmuk+RXeqZn+pO+gqDwoc4OLPFqIucqy6MyrzdHOVcp7rxuU Nhee4kJjGVJPpx08eTq12IL4G5+AvI2p+kA0ReOFE7xm/7hQ3EGDT/ecs sCptyXMvq3Hx80DJwIz1Tpu0XgvCiY0TiZ+ogE+05/2iyWy/TAuPPfN3L QVfSE8pXCQEniv7SbFVKesnzO81PDjKC6jMg2cVkaj1LuSlt+oiiv03jv w==; X-IronPort-AV: E=McAfee;i="6600,9927,10949"; a="5813334" X-IronPort-AV: E=Sophos;i="6.04,185,1695711600"; d="scan'208";a="5813334" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jan 2024 19:41:12 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.04,185,1695711600"; d="scan'208";a="16899350" Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.54.38.190]) by fmviesa002.fm.intel.com with ESMTP; 10 Jan 2024 19:41:11 -0800 Received: by tassilo.localdomain (Postfix, from userid 1000) id 3B47F301C53; Wed, 10 Jan 2024 19:41:11 -0800 (PST) From: Andi Kleen To: Gregory Price Cc: linux-mm@kvack.org, akpm@linux-foundation.org Subject: Re: [PATCH v6 00/12] mempolicy2, mbind2, and weighted interleave In-Reply-To: <20240103224209.2541-1-gregory.price@memverge.com> (Gregory Price's message of "Wed, 3 Jan 2024 17:41:57 -0500") References: <20240103224209.2541-1-gregory.price@memverge.com> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Wed, 10 Jan 2024 19:41:11 -0800 Message-ID: <87mstclep4.fsf@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 621E3100008 X-Stat-Signature: pp4erhg5pspd8i9tuyooq8m7tstrmopg X-Rspam-User: X-HE-Tag: 1704944473-442966 X-HE-Meta: U2FsdGVkX18pTu1+qQQb4HwXtnuzvIYnyc566TS0h2/LCzZR2tqYnRQaSGOPEklzCUbZHd4hpNDc5jyAYPCqrnXmTHyhnnaG2d8+OpX+UAx1yLrsjiln5stcTooIZPK+t8/10+4wUBBXYqC7nKhvMhBVKyFTPmAAm8w+f8wDX5ENqEWvV84zcEt85eKgw1XojQPju590hVrlcfSj6EOHTajGoGS27kbW2bWHkdUEtsxR9/kBvJ+mHF2GxY8NKesmd6unq/5pyQyF6oOPXVZ0BbJE6GwSSrVhK2iV08i2eywNGyvd6+behsZcGU9NdTe5Vnsegf557hYerOEnnOLE7nW9bRYi6r7GDjHx1HKyeLB5a4WEJO3XsrhqFaZY+l88YvolICt2+JdhdELycxv45xM2CLB1ZFlFBO8z4nIB46bIJy4PKXJLYiP8Cuc5krSsM5GfBDHtw0z3srMkxwieQ+f0irm9pNc/pv2n+lAMWxpGFmMj/1UmWultqCmTmKL+/D6kLq9IpWKhm4d3yddduJ6rabAmz8ayJsyub9/V6TjDucCKXJ6YWRv1W7r/rrrpFkzqu3dXkHLFYws2cWIvsY3GCtJxEkfaIiyWp0fjXPfITKvG8GgX6WAu4Di0XNr1lWOErA1SVe8Md2pajemO793F02yqPcaeAd8SQ+k9JOk2TtK4NCGx35zWbvTIgV7H5hlJDxzd3CsRevZ7riimp8c4qigopcLyaON27yNMH0zRhDLlOT8z9H5TdzRK2mRH9JKPHLYW39L7qoaJSkUSlOImyETalOgyzEIbL4TPSE8gDK1YTZRol2TiWbl0lXjppAJ1uXqpuVjKeHnU9wymUdE9nz/Ol2O+bhyyr9e4q80= 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: List-Subscribe: List-Unsubscribe: [sorry for the resend, fixed mailing list address] Gregory Price writes: > Weighted interleave is a new interleave policy intended to make > use of heterogeneous memory environments appearing with CXL. > > To implement weighted interleave with task-local weights, we > need new syscalls capable of passing a weight array. This is > the justification for mempolicy2/mbind2 - which are designed > to be extensible to capture future policies as well. I might be late to the party here, but it's not clear to me you really need the redesigned system calls. set_mempolicy has one argument left so it can be enhanced with a new pointer dependending on a bit in mode. For mbind() it already uses all arguments, but it has a flags argument. But it's unclear to me if a fully flexible weight array is really needed here anyways. Can some common combinations be encoded in flags instead? I assume it's mainly about some nodes getting preference depending on some attribute So if you add such a attribute, perhaps configurable in sysfs, and then have flags like give weight + 1 on attribute, give weight + 2 on attribute give weight + 4 on attribute. If more are needed there are more bits. That would be a much more compact and simpler interface. For set_mempolicy either add a flags argument or encode in mode. It would also shrink the whole patchkit dramatically and be less risky. You perhaps underestimate the cost and risk of designing complex kernel interfaces, it all has to be hardened audited fuzzed deployed etc. -Andi