From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2E01527E06C for ; Wed, 17 Dec 2025 05:53:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=198.175.65.16 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765950809; cv=fail; b=aJX3heWza1p+1J4Rli8mi0VXpXKuRMxHbQaMOAgnBxPTn8cQ8Hc19AZ8npSPnz//6EVCicjY+HzrsWpZRU+8qwVysDy1S/Vkg73cJxAIRU4jxIzAFckBte+4vhfqw37XXGQfJ4Q6CE/t3r7EXyre0Wk8acv2gxZ5ibtwNajTGnY= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765950809; c=relaxed/simple; bh=g93p9ezk/R1he1AH7jr8arKb+U/wWWwaj8MxwY83jK0=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=TIjpzrXTbZipTT0+GCXY/+JvvQbTbwS0TQ0iqjtAhumwygCgTNl/62EqDIZWsn9vFSh5viWEqO1ntKVD2ue5FJlx3wj2lQa/R69lXxJrU7BrLy8dP4TzpfFMIBBWRrBPhu3WXIfo86VIApsJXCep0lPMvDirGHMFKkQPj0Nlvak= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=WwGMDAGd; arc=fail smtp.client-ip=198.175.65.16 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="WwGMDAGd" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1765950807; x=1797486807; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=g93p9ezk/R1he1AH7jr8arKb+U/wWWwaj8MxwY83jK0=; b=WwGMDAGdy+6Pdvnn7EIyYJ/yGdALrUC728+2r9lBwfTfAa8Y1iZwqX11 bCDhIrjyXT4gsAjAm1+ssXR9CWZkpy1O2UUMcb4/P/mLS/iDCbunv1VDJ wexO4mZMQ5LUEvop83pnhDy+D7sDevATzqpHSg2ywiy0KcDAijp5PO8KX FFD5EK+ip1/mazLxxyznrwEFj8qZNLDwSaRobV6LPX7IHojOc+6LtanKV As5JEzMBzxg8gG96ncdjF+rqkvaaPcGh+ckNRsZx4FitzO9Yx+UpjmfHU drfIQPfV0mDVGmFCgz/zJtHBLA2r8W/7LdB6JxMpiSP/Bi2FEVZlqjgnK w==; X-CSE-ConnectionGUID: HBGWVjTORPWaZiDrAL+Xbg== X-CSE-MsgGUID: wgU3wLU/TL+xAi7+5vIUUQ== X-IronPort-AV: E=McAfee;i="6800,10657,11644"; a="68036988" X-IronPort-AV: E=Sophos;i="6.21,155,1763452800"; d="scan'208";a="68036988" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Dec 2025 21:53:26 -0800 X-CSE-ConnectionGUID: 568W2Ud4The/06WaxEKOUA== X-CSE-MsgGUID: 0Mt8tc7YScm8z1elP1CGhQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,155,1763452800"; d="scan'208";a="197963543" Received: from fmsmsx902.amr.corp.intel.com ([10.18.126.91]) by orviesa009.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Dec 2025 21:53:26 -0800 Received: from FMSMSX902.amr.corp.intel.com (10.18.126.91) by fmsmsx902.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.29; Tue, 16 Dec 2025 21:53:24 -0800 Received: from fmsedg901.ED.cps.intel.com (10.1.192.143) by FMSMSX902.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.29 via Frontend Transport; Tue, 16 Dec 2025 21:53:24 -0800 Received: from SN4PR2101CU001.outbound.protection.outlook.com (40.93.195.58) by edgegateway.intel.com (192.55.55.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.29; Tue, 16 Dec 2025 21:53:24 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=XSdbo7O8iut6/AV9mRiiv/v5i2e5p0c9KPdKEaidUEmDenk4tfF8kNG749iAODe1m/S1ZhUQ75TXgy/snusO8V07DBjNeTDOUNrsuM6kGGUPbqzNDT06BcelN/VYaAHaF5agGfmLv5+gGg3DboqnTKXZdFGrTOG1nZM8fSOSm405jF2BHxATFKBpjslCA9IVWpHiFqV+WO9uptD96YIPbcwPE69jUKEmrAe92hv/B8LDm+sdgnX9MA5F3jKdUNnrbHrYo8/noSV4+GzCxl57yGXl71uIR4H68Si7Rwl4yKjuLM7k3LESOQa2XXyZiQqyZLk8d7fuA6TNjkm0B6N9Ig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3GDoZ3NYSmbDCGX5MLqBtNu5tgXOVQLwI2BeIQcijD8=; b=Nbl1d7JzXeih8YCXKrh27+lRfAYh3Tj3WUlzylaZpkevR1tC24lrFWERYjDdVge1YvgsL4+Rb2kXeIPSI8JYoQjhom+b34Skr2cFjmIfKAeeyWcMJBNVF2mV4y1bDwMiAWuk/OeoaQ6VjMu0WfZfv6mrSZQWMgnMcuFMNsRQL0wYFF82fUdFvkI5v22iuQ01+9OhIZuciL69KQJaihQmwbcl71HWtdjFsBGBqYkw4Bk5BOUZx57uHHJRoPgL2kM/ISninDL2av+rc/rehXsbLX06nkFRRUknow4s1OH4uZaDw5AGmAY+D6wZDVC4hYZKfWTm3GT/F2jLPhduDuUlhQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from SJ2PR11MB7573.namprd11.prod.outlook.com (2603:10b6:a03:4d2::10) by SA2PR11MB4921.namprd11.prod.outlook.com (2603:10b6:806:115::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9412.13; Wed, 17 Dec 2025 05:53:22 +0000 Received: from SJ2PR11MB7573.namprd11.prod.outlook.com ([fe80::61a:aa57:1d81:a9cf]) by SJ2PR11MB7573.namprd11.prod.outlook.com ([fe80::61a:aa57:1d81:a9cf%3]) with mapi id 15.20.9434.001; Wed, 17 Dec 2025 05:53:22 +0000 Message-ID: Date: Tue, 16 Dec 2025 21:53:20 -0800 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/3] x86/resctrl: Add "*" shorthand to set minimum io_alloc CBM for all domains To: Aaron Tomlin , , , , , , , , CC: , References: <20251215230257.1798865-1-atomlin@atomlin.com> <20251215230257.1798865-4-atomlin@atomlin.com> From: Reinette Chatre Content-Language: en-US In-Reply-To: <20251215230257.1798865-4-atomlin@atomlin.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: MW4P221CA0016.NAMP221.PROD.OUTLOOK.COM (2603:10b6:303:8b::21) To SJ2PR11MB7573.namprd11.prod.outlook.com (2603:10b6:a03:4d2::10) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ2PR11MB7573:EE_|SA2PR11MB4921:EE_ X-MS-Office365-Filtering-Correlation-Id: 9d2565f2-64c8-44a8-9db3-08de3d309664 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|7416014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?U2ZoY1hHanRwY29pUEpnQkx4TDZxNDhJSXN2V1pjc3BKOWhVMnNWKzNpVDhC?= =?utf-8?B?ZGpsN0dER1JINXRqaUdtcWZ4MDR3Nkp5WUVDeFZHZFpDZVJJNWpPekREM3Ar?= =?utf-8?B?TVBTNU9tbFljbGdTZGxUS2hQWllMOVZTNWVPVktXOXh1d0s5dWZCVE9yRVlI?= =?utf-8?B?S2hzb3BxeTFwZHhOWkxqSndOQzY2RUM4RUM4N29HZ3lFZGRhbjhaUW44SDQw?= =?utf-8?B?YlRLamtNbGwyUFJ0MnZhMFpCZWR3d1g5MlNWOVBNMm40QmRwVjVvelhydnJX?= =?utf-8?B?aFVPdndLSlZwV2U3MHJaZUR0VFMzSlYvZC9QMFlxczEwek5IRzdQUE1WbjNL?= =?utf-8?B?VEZ5UmJwU0xMeDQ0Z3RaMDNjUTk3OWZUUGZzQlgxdktHSUdOckJpZ0FWRW53?= =?utf-8?B?VnJhbk9LSnNmcitnZWlEZEE0UitYcXFWa3RDYUdkVDZNWEt5Ylo4d0FnMWNY?= =?utf-8?B?SWU2dyt4VS9XWkZxQS9rdXMxbGs2N1hwdHNVWE9BSTR1MUpOWE9wOUtnOCt4?= =?utf-8?B?b280WXRQYXJ1ZjBjL05DVVhLd013TVJBT1MrdjQ1eTR6QUUzeHpBNlYvek1U?= =?utf-8?B?QUMvQW1jeDZqUlArRE1zNzhuRHl1bGRBZWVkUVh5cnViaE9vMU1pZkk0SklM?= =?utf-8?B?M0lmbHVZR3NYYzJFdFltL1ZGZzRSb2Q3bXRmaC9jUVoyNElMbEJFS2dlUGZr?= =?utf-8?B?VC9XYjlKdGl0N2hTMGtsMzYvRnd4eXc3WFA0bDdIZWVsVWZxbm5NanJvVHg3?= =?utf-8?B?dTAvMjJjdi9VRGljS2w1NXVTTzlqckxoaFJ3Ui9OYi9iLytnS3Q0YzcyNk9M?= =?utf-8?B?QUFRV3pqb3ZxVzFuVmlqWjBlRUhXaVViLzJlU2FqejFYZ09rK1VkWCsxUUU0?= =?utf-8?B?bWNYZ0drNDBCTVU1T3R3TGYxVWpRc0JlZHBpZ0Z3djdKbTRFK1VWa1JodGR1?= =?utf-8?B?am9FVDZlNGZFWW1qaE1YOWl3S2ZJTnluZVczOWFlTjZQQUY1MkRldGpoZFhz?= =?utf-8?B?ckFXa3hidHZyMm5yWDlIUUtDSjM5NXY1Z1RjVWl5d0k0UEo5LzVPaDJIbTcw?= =?utf-8?B?Z2gzQnZQcUdmNnlvNER4a3JGMDU1clI3UUVZNVM1ZG9CU2pzczNwVjcwUWpE?= =?utf-8?B?dmY1ZEczeTJQeHVhQlhuMmtTa25jc3krT2l5djltalRMRGRxdjh2ZXUvSmlW?= =?utf-8?B?ei9QeWh3TDkzZGdnY0JodFlLT2pEZG5QeFhuL0pOTm94ZDZHZTlYamF5VlIx?= =?utf-8?B?WTNLaEhSaFJLSVNBTGlwRU5MUjRZZHpMQUVrVEJqWlVjS0VZbERLdzhOcXlE?= =?utf-8?B?RTZHdVBwaDRlSlAxT1FvOFpMVEpKUFAzT25OR2NBUk5SZGxnaFlSTEsrNlAw?= =?utf-8?B?TWZPUDBEMUdEeEtYOXJrOXk3TDEvNkJhbCtoNXVpTXhwS0J2eDFJOFhjeTIv?= =?utf-8?B?YVlDM1JnQXN0Wno5bFlzMjl6bmgwb1FORVJhOWFmK1hzR0trRXgzc3kwSksx?= =?utf-8?B?NWtINm1HamRzTHZvWkgvWjF2cVo5VXdwdkVCVlZTRlFBY29WRTR3QkxTY1kw?= =?utf-8?B?c0JHVlNkOVFpakIyRXRpMnYveTdMT2g3bEF3ckpGbG5td1NpN0lFVnlwWnpE?= =?utf-8?B?TzVPTi9HL2VzTFlNaitLOG03dUg0cG9IK1VoeVhxU2RqVjNKd3VZOWJjZzNB?= =?utf-8?B?c3dlWTR4RzhUT2VCU25PQm9NNDRSS3lpaTBQeXZlOUU0OVA2NFh3dlQrVDJB?= =?utf-8?B?amtOcmZkNGtSTmRUZTB1MXpIQnhNSkcwdUY5WG1Tb2N3NXQrVGs0aTZBZWt3?= =?utf-8?B?dmpzTVFPOVdjZlJYZlUwMHJ4cVdUWGZuTjFrUkxLSVdQNUs4RGk4OStSRDlG?= =?utf-8?B?TFp6ZDRaRG0rQklTYjUrYXhnR0NhTFNIOUtrcVBxWDh0UTREd1lnQmVETCtZ?= =?utf-8?B?RVdWZy9Lckd6UGFuK3p1RCtJMGNYd2JEb1dXUTlvaURrNmZIMFJDRzJJaXox?= =?utf-8?B?a0QrUHA4aFVnPT0=?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SJ2PR11MB7573.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(7416014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MDU5aGlmNTdnSXF2L0J3eThiMDB5cjNLRWJ0MmNNZDdVQ2FtNFh2NGJJdU12?= =?utf-8?B?YjdmR2lUUjBoVUc2cHZXQ0tOSHIwTys0ODdoTmNyZTFRRWhnUG5ua2hSajZV?= =?utf-8?B?TFMyR21LTUt3cllKZkdOa216VjI5TGk4WHFRQUdUWlRJQUVnRnpMem9FNzlP?= =?utf-8?B?RFQ5VTIxbkNJZWJxc2R0RTRQbC9UUW9LaG53Z2hyZzJsV09HWFRuZnNCS24z?= =?utf-8?B?cVpRa1hmWUF1R0FUZlhTZ204YXJpRWxUaEEyZFIxcFR2dXBldHN3a3UvRFZM?= =?utf-8?B?dzB4UEpOSy9RNmd2MHFuWW9Fdm05c1hMTzJ1VlY4QnlBV3lacUtFSkREaGZk?= =?utf-8?B?VEMxaUtkd1Y4SWQ3NWtBVi9VY09aVEFvWHBHRzVnZ0ppZXZ6K2dLS2ZlNDNF?= =?utf-8?B?Q3FSQTJlRjhCY2dpZENhWFlmT2dpWGs5ZEx4OEc0dGtxOTVqaDYzUjlmSXg1?= =?utf-8?B?TzhLTE1ENTFhUzFzZGg3QjF1TVdMazdtQVdrREJRVlBaeWRlWnRlS2lGMkVk?= =?utf-8?B?RlY3NU01bmZzTFhpY29HNGQ2SkdRL2VuVG1EckJSa1A2cndKZ2gwaTZ6VDN6?= =?utf-8?B?bkkzY2Z0ODZBb2I5TGJrVXlyWGFZa0ZWa2pXb2lDTnpHKzYzbHV5cFJsT2xo?= =?utf-8?B?bm9FY01lVXgvdTR4QWZLR2VaSXIzMVlVZ2thbXY2Q0VINm4yMkoraGRIYWtE?= =?utf-8?B?Vk9DUzIwdUYrL1hndUFTVVNydTNNdVhUUFNQQmxPa20xNHpGZGNXajQ1OGJT?= =?utf-8?B?SWVpdE5SUElFbktRa2pIOXpiektiUWVES3RRUDNRS2l1Q0d5ZmFvZnlIR1F2?= =?utf-8?B?ZEtrVnBhbEMwVXFqeUlKWTVWR1JYcG1XWWlEZWE1NFlHcUhDUlJLYUl1ZXVz?= =?utf-8?B?bG1mT3RnU2R0NFlpbUpzUWR4QU9vWjdMOUtjWFFORGp1cjJ4QXpSQUxUbjEv?= =?utf-8?B?NFArNnhQWnB6WVVLYXdSZGdkNkp4cForVDNFY2NXOGMrSFJLRjc0TW9NRVJS?= =?utf-8?B?amVpTEExazdibmcvMkZFU1d1ODlDRHY4NytzNjYyUUJCVnVkNHU4bXViMndM?= =?utf-8?B?L3RHWGkxOEtYdnkzQzVjTGtCQXRaMGkwQStDNDZ2RW0vMlViUUZyYTJkbnla?= =?utf-8?B?eTJ0L3RJTGlKalRua1JhMTROeENvTTV0b0pvOFQvSyttSnB1RWlTU1NVQWVz?= =?utf-8?B?L0x0UHlkWlVEelJjc3gwYnE5am5VeVlxcTcrQ0MwblkzTldWK3F1RXBhd3Bz?= =?utf-8?B?YkJ3OHJHTHdHclE0TnVDK0NUMHRQaGI4eitNZDBqOUpGdnZCeEIyaWwyejhy?= =?utf-8?B?TGtMbWxQb1pvSFBVSlRrNlpwM25yUVhwMDM2ZWZPM3dFWjFMN2FqM0lGZ1Zj?= =?utf-8?B?MUM1QmFtVUZ5SGZ1cHNhalp2THpBMlAwUXNCekF6NnlNbjQxeUp2dFFPUXBK?= =?utf-8?B?Vm8yc2Znc0JBMm1YRDFqNUo4bkMxRjhpcnYrTmc1RFlnbzBCRFFlSStjN1JU?= =?utf-8?B?enp1aWRlVkd2V1p4QlNPTmUybUh4em5xaWJqRWN5MkVpNzhVSGl0bGJkT1pG?= =?utf-8?B?TTlpNndRWHB4VEcvMm5VejBNdGd4cUV6VzJwMzArY0pCSE9UVDJESkZhNjFY?= =?utf-8?B?d0JORllwR2tURUZBbmFWN0tiYVVNTzBCeGFueVV6cjlyaGxlaXgyZmw5ZHp1?= =?utf-8?B?UFJYVjBjM1VTa3MwSjk2c0lqYWdobGdhcFc5bnd2MUVqandiM0crY09vbWh6?= =?utf-8?B?NkVmd0F2YWI4OXR4dzdKOVdKcWJWMytuV0l6WFNVTmFOTWJsTitFdDBXNzlW?= =?utf-8?B?RGUvQ2I0Z2FRbElBQ1dFbjcwSjdwRHFyRjRraWF0VHJoS3RReEs2U1EwWXpD?= =?utf-8?B?VkRpVC9wQlVKcE1NRnlYMkNpMVpSb2tFSSt0Ni9UWG42NW51NUtBMG8rdXc2?= =?utf-8?B?MmNiZzZuVlM3UnFKdmJUSHpRVkw5WmszZW14Vy9obFpOdmpOM0ZwQ2pYR0RO?= =?utf-8?B?bjYwMEtDby9oSFBIS3VtcWVjTVZaT3ZVYzFDRDdvTjZqYVV2ZFhLVk5INC96?= =?utf-8?B?RDNmak1tdVVlVW9jODZhd0dhUlZNU3JCR3ljUXdKMlM2cnM3U2tMaktvenNQ?= =?utf-8?B?NkRMRGx5OWxQeHZlVHVVMmpIWlpTTEQyZEdOK010R3dtUE1leFcyc0l5QzNl?= =?utf-8?B?QlE9PQ==?= X-MS-Exchange-CrossTenant-Network-Message-Id: 9d2565f2-64c8-44a8-9db3-08de3d309664 X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB7573.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Dec 2025 05:53:22.5200 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: VRX0WGKxcdb+aU+CeVPpNB13vlsOcn8YvBZ/2+woHkw8spLrOt19X7WyWam+BBCwYLAKkK96iilRz0YJl3Iz872eH7aLOUDsCjbsdfxk2pc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR11MB4921 X-OriginatorOrg: intel.com Hi Aaron, On 12/15/25 3:02 PM, Aaron Tomlin wrote: > This patch introduces a special domain ID selector "*" for io_alloc_cbm Kernel code and patches to kernel have a couple of style requirements that are documented. It takes some getting used to but it is required that submissions follow the kernel style in order to be considered for inclusion. Documentation relevant to above are: Documentation/process/submitting-patches.rst: Consider whole document but specifically search for "This patch" for information related to above. Documentation/process/maintainer-tip.rst: Consider whole document but specifically consider "Changelog" relevant to this part. > that allows setting the CBM of each cache domain to its minimum number > of consecutive bits in a single operation. For example, writing "*=0" to Is there a reason to limit this implementation to only support the minimum CBM? This feature can easily enable a user to set identical CBM across all domains without the CBM being required to be the minimum CBM, no? > /sys/fs/resctrl/info/L3/io_alloc_cbm programs each domain's CBM to the > hardware-defined minimum, greatly simplifying automation and management > tasks. The user is required to specify the correct minimum stored in > /sys/fs/resctrl/info/L3/min_cbm_bits. > > Signed-off-by: Aaron Tomlin > --- > Documentation/filesystems/resctrl.rst | 10 ++ > arch/x86/kernel/cpu/resctrl/core.c | 2 +- > arch/x86/kernel/cpu/resctrl/ctrlmondata.c | 23 ++-- > fs/resctrl/ctrlmondata.c | 141 ++++++++++++++++------ > fs/resctrl/internal.h | 13 ++ > fs/resctrl/rdtgroup.c | 2 +- > include/linux/resctrl.h | 30 ++++- > 7 files changed, 174 insertions(+), 47 deletions(-) > > diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst > index 8c8ce678148a..9c128c8fba86 100644 > --- a/Documentation/filesystems/resctrl.rst > +++ b/Documentation/filesystems/resctrl.rst > @@ -215,6 +215,16 @@ related to allocation: > # cat /sys/fs/resctrl/info/L3/io_alloc_cbm > 0=00ff;1=000f > > + Set each CBM to their minimum number of consecutive bits. > + > + A special value "*" is required to represent all cache IDs. > + The user should specify the correct minimum stored in > + /sys/fs/resctrl/info/L3/min_cbm_bits. > + > + Example:: > + > + # echo "*=0" > /sys/fs/resctrl/info/L3/io_alloc_cbm > + > When CDP is enabled "io_alloc_cbm" associated with the CDP_DATA and CDP_CODE > resources may reflect the same values. For example, values read from and > written to /sys/fs/resctrl/info/L3DATA/io_alloc_cbm may be reflected by > diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c > index 3792ab4819dc..44aea6b534e0 100644 > --- a/arch/x86/kernel/cpu/resctrl/core.c > +++ b/arch/x86/kernel/cpu/resctrl/core.c > @@ -276,7 +276,7 @@ static void rdt_get_cdp_config(int level) > > static void rdt_set_io_alloc_capable(struct rdt_resource *r) > { > - r->cache.io_alloc_capable = true; > + r->cache.io_alloc.io_alloc_capable = true; > } > > static void rdt_get_cdp_l3_config(void) > diff --git a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c > index b20e705606b8..0f051d848422 100644 > --- a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c > +++ b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c > @@ -57,14 +57,19 @@ int resctrl_arch_update_domains(struct rdt_resource *r, u32 closid) > hw_dom = resctrl_to_arch_ctrl_dom(d); > msr_param.res = NULL; > for (t = 0; t < CDP_NUM_TYPES; t++) { > - cfg = &hw_dom->d_resctrl.staged_config[t]; > - if (!cfg->have_new_ctrl) > - continue; > - > - idx = resctrl_get_config_index(closid, t); > - if (cfg->new_ctrl == hw_dom->ctrl_val[idx]) > - continue; > - hw_dom->ctrl_val[idx] = cfg->new_ctrl; > + if (resctrl_should_io_alloc_min_cbm(r)) { > + idx = resctrl_get_config_index(closid, t); > + hw_dom->ctrl_val[idx] = apply_io_alloc_min_cbm(r); > + } else { > + cfg = &hw_dom->d_resctrl.staged_config[t]; > + if (!cfg->have_new_ctrl) > + continue; > + > + idx = resctrl_get_config_index(closid, t); > + if (cfg->new_ctrl == hw_dom->ctrl_val[idx]) > + continue; > + hw_dom->ctrl_val[idx] = cfg->new_ctrl; > + } > No. resctrl_arch_update_domains() is a helper to just program configurations. Please avoid bleeding feature specific handling into dedicated helpers. > if (!msr_param.res) { > msr_param.low = idx; > @@ -123,7 +128,7 @@ int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable) > { > struct rdt_hw_resource *hw_res = resctrl_to_arch_res(r); > > - if (hw_res->r_resctrl.cache.io_alloc_capable && > + if (hw_res->r_resctrl.cache.io_alloc.io_alloc_capable && > hw_res->sdciae_enabled != enable) { > _resctrl_sdciae_enable(r, enable); > hw_res->sdciae_enabled = enable; > diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c > index d2f9a4f2d887..a36b9055a1be 100644 > --- a/fs/resctrl/ctrlmondata.c > +++ b/fs/resctrl/ctrlmondata.c > @@ -688,7 +688,7 @@ int resctrl_io_alloc_show(struct kernfs_open_file *of, struct seq_file *seq, voi > > mutex_lock(&rdtgroup_mutex); > > - if (r->cache.io_alloc_capable) { > + if (r->cache.io_alloc.io_alloc_capable) { > if (resctrl_arch_get_io_alloc_enabled(r)) > seq_puts(seq, "enabled\n"); > else > @@ -712,13 +712,31 @@ static bool resctrl_io_alloc_closid_supported(u32 io_alloc_closid) > return io_alloc_closid < closids_supported(); > } > > +/** > + * resctrl_sync_cdp_peer - Mirror staged configuration to the CDP peer type > + * > + * @s: resctrl schema > + * @d: resctrl control domain > + * > + * The caller must ensure CDP is enabled for the resource and must be > + * called under the cpu hotplug lock and rdtgroup mutex > + */ > +static void resctrl_sync_cdp_peer(struct resctrl_schema *s, struct rdt_ctrl_domain *d) > +{ > + enum resctrl_conf_type peer_type; > + > + peer_type = resctrl_peer_type(s->conf_type); > + memcpy(&d->staged_config[peer_type], > + &d->staged_config[s->conf_type], > + sizeof(d->staged_config[0])); > +} > + > /* > * Initialize io_alloc CLOSID cache resource CBM with all usable (shared > * and unused) cache portions. > */ > static int resctrl_io_alloc_init_cbm(struct resctrl_schema *s, u32 closid) > { > - enum resctrl_conf_type peer_type; > struct rdt_resource *r = s->res; > struct rdt_ctrl_domain *d; > int ret; > @@ -731,11 +749,8 @@ static int resctrl_io_alloc_init_cbm(struct resctrl_schema *s, u32 closid) > > /* Keep CDP_CODE and CDP_DATA of io_alloc CLOSID's CBM in sync. */ > if (resctrl_arch_get_cdp_enabled(r->rid)) { > - peer_type = resctrl_peer_type(s->conf_type); > list_for_each_entry(d, &s->res->ctrl_domains, hdr.list) > - memcpy(&d->staged_config[peer_type], > - &d->staged_config[s->conf_type], > - sizeof(d->staged_config[0])); > + resctrl_sync_cdp_peer(s, d); > } > > ret = resctrl_arch_update_domains(r, closid); > @@ -903,49 +918,103 @@ int resctrl_io_alloc_cbm_show(struct kernfs_open_file *of, struct seq_file *seq, > return ret; > } > > +/** > + * parse_domain_cbm - Parse "domain=cbm" and return either side > + * > + * @line_ptr: Pointer to the input string > + * @out_val: Output from parsed value (either domain ID or CDM) > + * @which: Selector for which side to parse > + * > + * It is assumed that *line_ptr and *out_val are valid. > + * > + * Return: 0 on success and advance *line_ptr to point past the > + * delimiter, EINVAL on parsing error > + */ > +static inline int parse_domain_cbm(char **line_ptr, unsigned long *out_val, > + enum resctrl_kv_sel which) > +{ > + char *rhs, *lhs, *tok; > + unsigned int base; > + > + rhs = *line_ptr; > + > + lhs = strsep(&rhs, "="); > + if (!lhs || !rhs) > + goto err; > + > + if (which == RDT_PARSE_DOMAIN) { > + tok = lhs; > + base = 10; > + } else { > + tok = rhs; > + base = 16; > + } > + tok = strim(tok); > + > + if (kstrtoul(tok, base, out_val)) > + goto err; > + > + *line_ptr = rhs; > + return 0; > +err: > + rdt_last_cmd_puts("Invalid domain=cbm: missing '=' or non-numeric value\n"); > + return -EINVAL; > +} Why is this new parser needed? > + > static int resctrl_io_alloc_parse_line(char *line, struct rdt_resource *r, > struct resctrl_schema *s, u32 closid) > { > - enum resctrl_conf_type peer_type; > struct rdt_parse_data data; > struct rdt_ctrl_domain *d; > - char *dom = NULL, *id; > - unsigned long dom_id; > + char *cbm = NULL; > + unsigned long out_val; > + int ret; > > -next: > - if (!line || line[0] == '\0') > - return 0; > + if (line[0] == '*') { > + ret = parse_domain_cbm(&line, &out_val, RDT_PARSE_CBM); > + if (ret) > + return ret; > > - dom = strsep(&line, ";"); > - id = strsep(&dom, "="); > - if (!dom || kstrtoul(id, 10, &dom_id)) { > - rdt_last_cmd_puts("Missing '=' or non-numeric domain\n"); > + if (out_val == r->cache.min_cbm_bits) { This does not look right. If I understand correctly out_val contains the user provided value/CBM, that is if user provided "*=3" then out_val contains "3". This value is in turn compared against the *number of bits* required. First, if indeed just forcing user to set the minimum CBM (which I already mentioned seems restrictive) then if out_val is "3" and min_cbm_bits is "2" then this check will fail while the user indeed did set the minimum CBM, no? Additionally, user providing value of 6 or C or any other value with two consecutive bits set would also be a valid value as a "minimum", no? This additional parsing and checks adds unnecessary complexity. Just keep original parsing that relies on parse_cbm() that calls cbm_validate() that ensures the provided CBM is valid for this resource while taking min_cbm_bits into account. > + r->cache.io_alloc.io_alloc_min_cbm = true; > + return 0; If I understand correctly the parsing discards user provided value. If this check thinks it needs to program the min CBM it appears to program the min CBM via a backdoor in the config write helper that circumvents the flow used by everything else in resctrl that first stages the values and then calls the config helper to write to hardware. This is not acceptable. Please integrate any new feature into existing flows that follow existing patterns. Punching a feature specific back door via this new state (io_alloc_min_cbm) is not appropriate. > + } > + rdt_last_cmd_puts("Invalid io_alloc min CBM\n"); > return -EINVAL; > } > > - dom = strim(dom); > - list_for_each_entry(d, &r->ctrl_domains, hdr.list) { > - if (d->hdr.id == dom_id) { > - data.buf = dom; > - data.mode = RDT_MODE_SHAREABLE; > - data.closid = closid; > - if (parse_cbm(&data, s, d)) > - return -EINVAL; > - /* > - * Keep io_alloc CLOSID's CBM of CDP_CODE and CDP_DATA > - * in sync. > - */ > - if (resctrl_arch_get_cdp_enabled(r->rid)) { > - peer_type = resctrl_peer_type(s->conf_type); > - memcpy(&d->staged_config[peer_type], > - &d->staged_config[s->conf_type], > - sizeof(d->staged_config[0])); > + while (line && line[0] != '\0') { > + bool found = false; > + > + cbm = strsep(&line, ";"); > + ret = parse_domain_cbm(&cbm, &out_val, RDT_PARSE_DOMAIN); > + if (ret) > + return ret; > + > + cbm = strim(cbm); > + list_for_each_entry(d, &r->ctrl_domains, hdr.list) { > + if (d->hdr.id == out_val) { > + data.buf = cbm; > + data.mode = RDT_MODE_SHAREABLE; > + data.closid = closid; > + if (parse_cbm(&data, s, d)) > + return -EINVAL; > + /* > + * Keep io_alloc CLOSID's CBM of CDP_CODE and CDP_DATA > + * in sync. > + */ > + if (resctrl_arch_get_cdp_enabled(r->rid)) > + resctrl_sync_cdp_peer(s, d); > + found = true; > + break; > } > - goto next; > } > + > + if (!found) > + return -EINVAL; > } > > - return -EINVAL; > + return 0; > } I agree with Babu [1]. This is a lot of complexity just to support handling of an additional character. resctrl does a lot of parsing of per-domain user space input and the current implementation follows the same pattern used throughout resctrl. Introducing a new pattern and parser unique to IO alloc feature adds unnecessary complexity. Simple and consistent is better. I considered your response [2] but to me this code is not more readable than a simple implementation built on top of existing, familiar, and consistent patterns. Another motivation from [2] is that this is easier to maintain but I fail to see that. About the motivation from [2] for "possible enhancements down the line" ... when/if need for an enhancement is required then code can be refactored to support it. On a workflow note: please allow for discussions about your submission. Taking a long time to respond and then responding that you disagree with feedback immediately followed by a new version of the series that does not address feedback is not productive. Reinette [1] https://lore.kernel.org/lkml/239e3a89-1075-439b-bf1c-d2be5be5c30c@amd.com/ [2] https://lore.kernel.org/lkml/5xlapgkp5bktan7xhy6l6b7c4qgeje7weu4cy6cbuux5npwijo@lhf5uvtuns5k/