Message-ID: <72b6ec8b-f141-3807-d7f2-f853b0f0b76c@amd.com>
Date:   Mon, 13 Feb 2023 11:22:12 +0530
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Subject: Re: [RFC PATCH 0/5] Memory access profiler(IBS) driven NUMA balancing
Content-Language: en-US
To:     "Huang, Ying" <ying.huang@intel.com>
Cc:     linux-kernel@vger.kernel.org, linux-mm@kvack.org, mgorman@suse.de,
        peterz@infradead.org, mingo@redhat.com, bp@alien8.de,
        dave.hansen@linux.intel.com, x86@kernel.org,
        akpm@linux-foundation.org, luto@kernel.org, tglx@linutronix.de,
        yue.li@memverge.com, Ravikumar.Bangoria@amd.com
References: <20230208073533.715-1-bharata@amd.com>
 <878rh2b5zt.fsf@yhuang6-desk2.ccr.corp.intel.com>
From:   Bharata B Rao <bharata@amd.com>
In-Reply-To: <878rh2b5zt.fsf@yhuang6-desk2.ccr.corp.intel.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VkRQcm5nNDF2aWJEaGl0NG45KzlnOGJwSUdhNk5sbWhwVWE5RkkybVdlRmEv?=
 =?utf-8?B?b01JU05TTCtrd0dRdmdza3dKaGxXSHBib3RkQUUzbjB1d0kzaGxtb2FzSVFh?=
 =?utf-8?B?dHMyTGZWa2t3K3JveVBSSXN4STdTUTc5NnpDRS9ZTkFPWEppbUg5eDMyTE52?=
 =?utf-8?B?MlE3dStCUUxLUUlWaGYxT0MvTVJZVTZHVTVEZkVhLzJBTUhkZ29CN0RJNmli?=
 =?utf-8?B?TW1jYVFKeFFsVnp6eFBmRnpTa3dqVjc0SWRlL1ZvMmtuYVhlalhUWUF5RklH?=
 =?utf-8?B?cjI4bE5aNVBhZWhIWjVBOU85WlNRNndJaHdyaGhHZUx5OS8xWVpva1FlckIy?=
 =?utf-8?B?MVFGcWtpYUtWWVVwcGFFd1NpalhlVzZadEtYZVNtdWdDNjREbnZUOUVIL2Ja?=
 =?utf-8?B?ZzRmdHFUcnhoeGY0S0puMHlLNG5OdzB6QWNnYVk4QUVEcm9odGE2Nzl6MDl1?=
 =?utf-8?B?K3g4QjJ5Z051bndnWEVOYVU1UnVRR2FxelhwOFZhcVRmU2JtaGpNVU5vTUIx?=
 =?utf-8?B?ZGM3eGtpYUVBRDZ3bCtWWGZ5MmtaejQ3WVhlL0JyNUJsRk5ZUi8zN2lQejlj?=
 =?utf-8?B?S1V4YXFoNGd6dXpmU3dsTm1scHNoRXp0SWxUNW9OaytrOFNYOHo2bWRFbnNB?=
 =?utf-8?B?S1VSYTZWRnpLaGxEUWlQc25oVmZSZVlCRGRRVS9vZXdwMzQxYlJDaDduaHhv?=
 =?utf-8?B?US91U0V2ZXMrMTV0aG9SOUJsRm83d29KN2UyUHNtMGVLQlowblhBaVhQc1VK?=
 =?utf-8?B?NWEwN3FsdEZRNm1VTEN6anBxeEY2Z1Y5bVV0Wk1lMmRoSWZ6UUhBcDY3UmdK?=
 =?utf-8?B?eHVBeGQ1alR6SnN3YXVKZkNaTmlWejBGWFUxUzBhUVhNaGlEWXFoS2RDVTVm?=
 =?utf-8?B?OFVydC9NZ25mWncrcjNEVXpBMFhBYmVPM1crL29SZWd5bW5TUUR0N3ZhSHpS?=
 =?utf-8?B?NSt0R3RFc3F5RUp5VGJRM2N5LzkyT2dNbXVYQndza3NEdlJhaG05bG5oVTly?=
 =?utf-8?B?Mlk5aEdFeXc2TkVsQjBLeW9KQm9IdDV0VnVxeHhhd3V5YTB1VkhwMEVCaHVh?=
 =?utf-8?B?Mm1DTGN5SkQ0RUFQU1RQZnZaSDkrSzllQXNvbHZwZ2RTSVF2aFlQZmN3L1dK?=
 =?utf-8?B?c3RhcWhraGlReEJVZ2hlZEpwQlE0WWlISmdxNkVndG1pblRBUERCVmw0TE9N?=
 =?utf-8?B?Y21sSkZGUTkyMUNFQnZEVFh1N3ByOTBoT0RWVmNTUzVpaDlNME1xT3lOK2hm?=
 =?utf-8?B?YUpKb2UxcjZIUTZia0lHMEhhMTB0M1pHTEc2ay80TTVaUE5sRU9OY1hKK0JR?=
 =?utf-8?B?TGc0Ni9KeW80RzdzSEdraGFGbXhjS3l1a1ViQTRpZE9sdDdKTC9ZV2lSUGh3?=
 =?utf-8?B?LzBzRFFtSi9JS2l2SzY3V2cxZVpIMk5HQkpITUJVZTIrRE82cE83cEtYWWgx?=
 =?utf-8?B?N1p5VkE0aHBSY0NobUJMTnd2bHVPZFJSZTBFS0NtWEtvdlhhd2gxMkI4TzRj?=
 =?utf-8?B?YnB2eEc1VnpSUXViSVBMOHR6c014Q0pGdm90NTkyUnZPeXFSMi9PVE4wdmlC?=
 =?utf-8?B?YXh4V0RhNjNkdFdORHBGZWlZV3QyYkdGZDBoQW9hbDl5NGh3RVRJbWZqS2Ir?=
 =?utf-8?B?ZHRhUTdROFZOV200VjE2QUxWMTJ5RGdOMHJINjRJNmZiTVFGOE0rMVluSkh1?=
 =?utf-8?B?RFl3U0RLb1Ztc2xhWVZlcGMrZnFYUmZNeUdtbzltRm5JdVhMSXdHT2pUMW1R?=
 =?utf-8?B?ZWNieEFKY3V1MWVtN0VGcHUzWWd3YXRZRzBGczQyNC8wTVF0WTBnRFNLb1Nj?=
 =?utf-8?B?TVVCa2g3TVl1OE1Ic3pMckE1dm5SN3h4cmNEWUR4eHhObm1mY3NLZktPZmVJ?=
 =?utf-8?B?dTZFSUFnL1lGVzMveUI0czliTTNVbXB5VTVhOFY1TjdjcUc0VGFtOGFNbUV4?=
 =?utf-8?B?SFBQbXVNK3k0bnVtREtrNkdvSXpnc1ZVbWpGQVZkRlF1bTI0NS85WHlrVCtm?=
 =?utf-8?B?L0gyalNoNlBpcEc4cnZrcmZpNlhqa0cxM2dTeTF2bStYbFJTTmQ4alZxemM5?=
 =?utf-8?B?RnltbEdwRGtmRXNEaTlaSkd3V21WK2MzY0VGcTlyT2EvRUV0MUhMRmx2ZFll?=
 =?utf-8?Q?ZfP60HKlJHVMKzgM+CQ/TtFb3?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ee135fba-79a1-4d6e-e42e-08db0d867aec
X-MS-Exchange-CrossTenant-AuthSource: IA1PR12MB6434.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Feb 2023 05:52:24.5006
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: j9rOOnAC+E5Nn7il1o9sGxYeHFSkeR/g8OaM3gAShG6YhPNwuC74GfooQP7WmWlmEIo+kIUU7AlDEFr7kbYAEA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8758
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2/13/2023 8:56 AM, Huang, Ying wrote:
> Bharata B Rao <bharata@amd.com> writes:
> 
>> Hi,
>>
>> Some hardware platforms can provide information about memory accesses
>> that can be used to do optimal page and task placement on NUMA
>> systems. AMD processors have a hardware facility called Instruction-
>> Based Sampling (IBS) that can be used to gather specific metrics
>> related to instruction fetch and execution activity. This facility
>> can be used to perform memory access profiling based on statistical
>> sampling.
>>
>> This RFC is a proof-of-concept implementation where the access
>> information obtained from the hardware is used to drive NUMA balancing.
>> With this it is no longer necessary to scan the address space and
>> introduce NUMA hint faults to build task-to-page association. Hence
>> the approach taken here is to replace the address space scanning plus
>> hint faults with the access information provided by the hardware.
> 
> You method can avoid the address space scanning, but cannot avoid memory
> access fault in fact.  PMU will raise NMI and then task_work to process
> the sampled memory accesses.  The overhead depends on the frequency of
> the memory access sampling.  Please measure the overhead of your method
> in details.

Yes, the address space scanning is avoided. I will measure the overhead
of hint fault vs NMI handling path. The actual processing of the access
from task_work context is pretty much similar to the stats processing
from hint faults. As you note the overhead depends on the frequency of
sampling. In this current approach, the sampling period is per-task
and it varies based on the same logic that NUMA balancing uses to
vary the scan period.

> 
>> The access samples obtained from hardware are fed to NUMA balancing
>> as fault-equivalents. The rest of the NUMA balancing logic that
>> collects/aggregates the shared/private/local/remote faults and does
>> pages/task migrations based on the faults is retained except that
>> accesses replace faults.
>>
>> This early implementation is an attempt to get a working solution
>> only and as such a lot of TODOs exist:
>>
>> - Perf uses IBS and we are using the same IBS for access profiling here.
>>   There needs to be a proper way to make the use mutually exclusive.
>> - Is tying this up with NUMA balancing a reasonable approach or
>>   should we look at a completely new approach?
>> - When accesses replace faults in NUMA balancing, a few things have
>>   to be tuned differently. All such decision points need to be
>>   identified and appropriate tuning needs to be done.
>> - Hardware provided access information could be very useful for driving
>>   hot page promotion in tiered memory systems. Need to check if this
>>   requires different tuning/heuristics apart from what NUMA balancing
>>   already does.
>> - Some of the values used to program the IBS counters like the sampling
>>   period etc may not be the optimal or ideal values. The sample period
>>   adjustment follows the same logic as scan period modification which
>>   may not be ideal. More experimentation is required to fine-tune all
>>   these aspects.
>> - Currently I am acting (i,e., attempt to migrate a page) on each sampled
>>   access. Need to check if it makes sense to delay it and do batched page
>>   migration.
> 
> You current implementation is tied with AMD IBS.  You will need a
> architecture/vendor independent framework for upstreaming.

I have tried to keep it vendor and arch neutral as far
as possible, will re-look into this of course to make the
interfaces more robust and useful.

I have defined a static key (hw_access_hints=false) which will be
set only by the platform driver when it detects the hardware
capability to provide memory access information. NUMA balancing
code skips the address space scanning when it sees this capability.
The platform driver (access fault handler) will call into the NUMA
balancing API with linear and physical address information of the
accessed sample. Hence any equivalent hardware functionality could
plug into this scheme in its current form. There are checks for this
static key in the NUMA balancing logic at a few points to decide if
it should work based on access faults or hint faults.

> 
> BTW: can IBS sampling memory writing too?  Or just memory reading?

IBS can tag both store and load operations.

> 
>> This RFC is mainly about showing how hardware provided access
>> information could be used for NUMA balancing but I have run a
>> few basic benchmarks from mmtests to check if this is any severe
>> regression/overhead to any of those. Some benchmarks show some
>> improvement, some show no significant change and a few regress.
>> I am hopeful that with more appropriate tuning there is scope for
>> futher improvement here especially for workloads for which NUMA
>> matters.
> 
> What's your expected improvement of the PMU based NUMA balancing?  It
> should come from reduced overhead?  higher accuracy?  Quicker response?
> I think that it may be better to prove that with appropriate statistics
> for at least one workload.

Just to clarify, unlike PEBS, IBS works independently of PMU.

I believe the improvement will come from reduced overhead due to
sampling of relevant accesses only.

I have a microbenchmark where two sets of threads bound to two 
NUMA nodes access the two different halves of memory which is
initially allocated on the 1st node.

On a two node Zen4 system, with 64 threads in each set accessing
8G of memory each from the initial allocation of 16G, I see that
IBS driven NUMA balancing (i,e., this patchset) takes 50% less time
to complete a fixed number of memory accesses. This could well
be the best case and real workloads/benchmarks may not get this much
uplift, but it does show the potential gain to be had.

Thanks for your inputs.

Regards,
Bharata.