Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp241516imm; Wed, 3 Oct 2018 15:19:56 -0700 (PDT) X-Google-Smtp-Source: ACcGV619KU5kk+Lv9WBDMudbzsrhkLHbOdJByAWPpHjTnLhnB6J+wriKMim8xFZYrxHVt8aahsBE X-Received: by 2002:a17:902:2f41:: with SMTP id s59-v6mr3594790plb.240.1538605196225; Wed, 03 Oct 2018 15:19:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538605196; cv=none; d=google.com; s=arc-20160816; b=IPdZCk3men8ZsbHW3WxxZ2KefOxpJvXCLt8xEK+H8osy9tDwbDMi6G8wSwPXIuhWvW XwDwEGmaCPzBYmC5etK6C0x7vNDmTEMQafcGvmUm4g6GFdcw7rkWJVXm+GWBq70E3Y+U TQOBNDVaGpO+/JP9I9j2opzR0KHMX8g7iIWS5KWIgZH04TEjqP8yxWFeWUTMccO+JVNU VrDwzkzl4G/ppI2mfT7q91K+MnWcRZggKI0UjqG1uFNYXK4ttbOzfM8dmGxeyo+2gij3 tk23+uNroEQtfDJakLMQVfWzBMIX5sSq/QrotSvStaoIHDcW7X04j8NIFXhhW3CnIv95 iPxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=/VQbrHd9oiMKdy3YUPeSIeJ9Q57eC7Zsni/ARsIqDgQ=; b=tf5wAZT+RWrPBfLrZknOascaQD0SIizudQn58No30WFw3zaOxnOZpRnZ169jsw5UGq t/ENZWSr4CXXa9NtXY7bRKVn0q3l3f1gsTlc1H5Lg4UTX0n571etet9+JCZQGYwjR1do i4XrfwgZoLzRqSdB+J8CtHU/HWnLVz9IxEMxg0SanlNipe8sXJZXGBJpeGBE2+4Xq2Yn wPri9VQ2OCmAsr5wI/DMavkmM4uQuo0jJth8btfsL5oSRgPUm7ySSpgikDxoBH6V6p6V P7pyPhHvA9d4jpjigSQZ6MtpFklXm48Gr0zp8YpVwyyXsgnY1uDR+iXSfc1SaFMUtT2T 3DZQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l2-v6si2935794pgc.196.2018.10.03.15.19.41; Wed, 03 Oct 2018 15:19:56 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727143AbeJDFI5 (ORCPT + 99 others); Thu, 4 Oct 2018 01:08:57 -0400 Received: from mga02.intel.com ([134.134.136.20]:62846 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725922AbeJDFI5 (ORCPT ); Thu, 4 Oct 2018 01:08:57 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Oct 2018 15:18:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,337,1534834800"; d="scan'208";a="91965083" Received: from rchatre-s.jf.intel.com ([10.54.70.76]) by fmsmga002.fm.intel.com with ESMTP; 03 Oct 2018 15:17:41 -0700 From: Reinette Chatre To: tglx@linutronix.de, fenghua.yu@intel.com, tony.luck@intel.com Cc: jithu.joseph@intel.com, gavin.hindman@intel.com, dave.hansen@intel.com, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org, Reinette Chatre Subject: [PATCH V2 0/3] x86/intel_rdt: Fix exclusive mode with CDP resources Date: Wed, 3 Oct 2018 15:17:00 -0700 Message-Id: X-Mailer: git-send-email 2.17.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Changes in V2: - Have the new rdt_cdp_peer_get() return EINVAL instead of ENOENT when only one of the CDP peers have a rdt_domain associated with it. - Rename _rdtgroup_cbm_overlaps() to __rdtgroup_cbm_overlaps() to stand out more. - Fix kernel-doc to match function parameter name. - Rename rdtgroup_cbm_overlaps()'s _cbm function parameter to cbm. - Simplify the code in rdtgroup_cbm_overlaps() to make the flow more obvious. Nothing (apart from diffstat) changed below since original submission. Dear Maintainers, CDP resources do not currently behave as expected when there are resource groups with mode 'exclusive'. In the example below it was possible to create two resource groups, p1 and p2, that are both in exclusive mode but their usage of the underlying L2 cache actually overlaps. root@glk:/sys/fs/resctrl# ls cpus cpus_list info mode p1 p2 schemata size tasks root@glk:/sys/fs/resctrl# cat schemata L2DATA:0=fff0 L2CODE:0=fff0 root@glk:/sys/fs/resctrl# cat mode shareable root@glk:/sys/fs/resctrl# cat p1/schemata L2DATA:0=0003 L2CODE:0=000c root@glk:/sys/fs/resctrl# cat p1/mode exclusive root@glk:/sys/fs/resctrl# cat p2/schemata L2DATA:0=000c L2CODE:0=0003 root@glk:/sys/fs/resctrl# cat p2/mode exclusive root@glk:/sys/fs/resctrl# cat info/L2CODE/bit_usage 0=SSSSSSSSSSSSEEEE root@glk:/sys/fs/resctrl# cat info/L2DATA/bit_usage 0=SSSSSSSSSSSSEEEE root@glk:/sys/fs/resctrl# In the above example, the CBM of L2DATA in p1 overlaps with the CBM of L2CODE in p2 while they are both in exclusive mode. While it may reflect no overlap among the L2DATA resources specifically it does actually imply overlap of use of the underlying hardware that is not the intention of 'exclusive' mode. This happens because the current implementation treats L2CODE and L2DATA as totally independent, when it is actually referring to the same underlying hardware. This series fixes the potential for overlap of hardware resource use when resource groups are in 'exclusive' mode by ensuring that if there is a CDP peer on the same hardware then any overlap test would consider it also. Allocations of data and code resources within the same exclusive resource group are allowed to overlap. Your feedback will be greatly appreciated. Reinette Reinette Chatre (3): x86/intel_rdt: Introduce utility to obtain CDP peer x86/intel_rdt: CBM overlap should also check for overlap with CDP peer x86/intel_rdt: Fix initial allocation to consider CDP arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 133 ++++++++++++++++++++++- 1 file changed, 127 insertions(+), 6 deletions(-) -- 2.17.0