Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp609480imm; Fri, 31 Aug 2018 08:36:09 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYhD1FN4TIkaLY7mZ9d0Tkk+btKipS4ESXNNJNTu4EQBOaiMR1Tsmyps8N49OEvz9KUEicb X-Received: by 2002:a63:c941:: with SMTP id y1-v6mr14606125pgg.331.1535729769285; Fri, 31 Aug 2018 08:36:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535729769; cv=none; d=google.com; s=arc-20160816; b=bbAEX5nIb31di+vrZ6+z30t5Bj3pAfrmylaF+tqUT1q4/rX35UjAjDkrB/0s48BjkK vsD+UM2+xFpKnUqYi/qONO7UaOYilvM5KDODfUrTJua5Nx+Y0Vu9XtTLquGGG2mTTofc yGGPfPkZv2UiIB5yzA5J1xxyPozhB4zjqntmLdWBAe9ktSOdBUmyiaxTDl2C51TuPB80 oXQswop+aJuRT7BbOafri0fR+NE03onQMTbu4ntjlV7FP3NZiwTOav95tPjFVTLHPvgU MXt0pzWPUYQVIoCdPSpWhRuJgGDe2eIBL8nZHvs2SlnkcGteN7F+wpZs4jYapYLW0N93 WE/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=d+A5M/FMAGR8ggpZLLUoLVY4vmIAt3ISsbvdRCBJcDQ=; b=YeESWAX2m1LG4F3fkcZbx2vsxk8A8jazLejcmWDUAkTwkF2l6xo/JkdNdCZ0CjTDli p8GkT1Cb7WNQfCZuHGwCcYwHdkto8tCj0cdTNkc00X9dMa1BBebPwJt5jktWk8xaD01f nv7qAt3NAO9tbxyii/EU6SiNRqo5V7lluxDfFeuArKut5SZkK8GPaDw83FIDSWzSAJDe AiOlKBYmRwGyAKPf9hZDNzw6geHxeTtk003plgRW1nZp4CkBREmZ9i+6e2dvwtTEq5SI 2gcY6daVKVGHLsutJxDFLmScBuTg6DZg2fBaLPE1Ls4bdJ0l9hoHmDwEaw9wo00GZ4sZ ktDA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c1-v6si10434501pli.192.2018.08.31.08.35.54; Fri, 31 Aug 2018 08:36:09 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729035AbeHaTmv (ORCPT + 99 others); Fri, 31 Aug 2018 15:42:51 -0400 Received: from foss.arm.com ([217.140.101.70]:60546 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727286AbeHaTmv (ORCPT ); Fri, 31 Aug 2018 15:42:51 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E493A18A; Fri, 31 Aug 2018 08:34:48 -0700 (PDT) Received: from [10.4.12.81] (melchizedek.Emea.Arm.com [10.4.12.81]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 62EB93F5BD; Fri, 31 Aug 2018 08:34:47 -0700 (PDT) Subject: Re: [RFC PATCH 00/20] x86/intel_rdt: Start abstraction for a second arch To: Fenghua Yu Cc: linux-kernel@vger.kernel.org, x86@kernel.org, Thomas Gleixner , Tony Luck , Ingo Molnar , H Peter Anvin , Reinette Chatre , Vikas Shivappa References: <20180824104519.11203-1-james.morse@arm.com> <20180827142204.GA223688@romley-ivt3.sc.intel.com> From: James Morse Message-ID: Date: Fri, 31 Aug 2018 16:34:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180827142204.GA223688@romley-ivt3.sc.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Fenghua, On 27/08/18 15:22, Fenghua Yu wrote: > On Fri, Aug 24, 2018 at 11:44:59AM +0100, James Morse wrote: >> ARM have some upcoming CPU features that are similar to Intel RDT. Resctrl >> is the defacto ABI for this sort of thing, but it lives under arch/x86. >> >> To get existing software working, we need to make resctrl work with arm64. >> This series is the first chunk of that. The aim is to move the filesystem/ABI >> parts into /fs/resctrl, and implement a second arch backend. >> >> >> What are the ARM features? >> Future ARM SoCs may have a feature called MPAM: Memory Partitioning and >> Monitoring. This is an umbrella term like RDT, and covers a range of controls >> (like CAT) and monitors (like MBM, CMT). > > Please send a link to MPAM spec. I'm afraid there isn't a public spec yet, hopefully September/October. >> This series is almost all about CDP. MPAM has equivalent functionality, but >> it doesn't need enabling, and doesn't affect the available closids. (I'll >> try and use Intel terms). MPAM expects the equivalent to IA32_PRQ_MSR to >> be configured with an Instruction closid and a Data closid. These are the >> same for no-CDP, and different otherwise. There is no need for them to be >> adjacent. >> >> To avoid emulating CDP in arm64's arch code, this series moves all the ABI >> parts of the CDP behaviour, (half the closid-space, each having two >> configurations) into the filesystem parts of resctrl. These will eventually >> be moved to /fs/. > > Do you have the patches that moves code to /fs/resctrl? Not currently in a usable state, I haven't successfully rebased this stuff over the mba_sc additions yet. My intention was to make any abstracting changes where the code is now, then move the fs-specific parts in one go when its done. This is so the work can be broken up into manageable chunks. >> MPAMs control and monitor configuration is all memory mapped, the base >> addresses are discovered via firmware tables, so we won't have a table of >> possible resources that just need alloc_enabling. >> >> Is this it? No... there are another two series of a similar size that >> abstract the MBM/CMT overflow threads and avoid 'fs' code accessing things >> that have moved into the 'hw' arch specific struct. >> >> >> I'm after feedback on the general approach taken here, bugs, as there are >> certainly subtleties I've missed, and any strong-opinions on what should be >> arch-specific, and what shouldn't. >> >> This series is based on v4.18, and can be retrieved from: >> git://linux-arm.org/linux-jm.git -b mpam/resctrl_rework/rfc_1 > > Could you please publish MPAM patches as well? Then we can have better idea > on ARM's specific code. This patch set only has Intel RDT part. You want to see it all at once (great!). I'm not quite ready with all this yet, so it will be a while. I assumed 'all at once' would be to much to ask from reviewers, hence this attempt to break it into small chunks and post it over a longer period of time. Thanks, James