From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) (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 316392C86D for ; Sat, 13 Sep 2025 07:57:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=205.220.177.32 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757750230; cv=fail; b=pyuKkIS76qoCTNoZjNRyhJdjAvA4BIKaPUVLC0hZLqRehyRhXhOX1V47GMNwAkT5cV/b/aOeWjs+KM984N9lbRsjfRevGJqW+JEbbR66iDps8DT/NjNkWDu3YMVH37xza9OBLl9obxVcTHkwTtWoBBpyLitVutL5Xn75ixPtaC0= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757750230; c=relaxed/simple; bh=lxGMiPla2ay61Qo5b8M6tylHU3xkqOkFtnU3SYGnJTg=; h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To: Content-Type:MIME-Version; b=uOrp7gFgTCsDCfIWt8I5v5q9m9SeJE+E+Zl22MWtiW2mhuU3t3Gx9hu347i1yovDyf60IGFXZ00RXz8aSIvHanPzspEDQkyvljJ6diyvHbndVLIMRJEL3RLU790KqhTauggKdvXddPWErbPvKSTHq9kYa9ceGieO6WQ5bwIpZM4= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com; spf=pass smtp.mailfrom=oracle.com; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b=q7cNV6we; dkim=pass (1024-bit key) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b=BJ/Toiyo; arc=fail smtp.client-ip=205.220.177.32 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oracle.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="q7cNV6we"; dkim=pass (1024-bit key) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b="BJ/Toiyo" Received: from pps.filterd (m0246631.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 58D4oILE004721; Sat, 13 Sep 2025 07:56:42 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= corp-2025-04-25; bh=w5j0kZ3UhnZ4UyoT+nAuRzx03i/iK2SCABNlpB7lbcs=; b= q7cNV6weP5AD6vgc0HKCPJ+HWqCJK3SIsUjxEkzSMI2lZ8pUILny4iL/Y2GCuNkF /NhEWfa9oG8HSKCi4W9ygmKaoBz268fQGk5gW0MAhrWOeHbrRoCIvPIuJBpMiBlX mmvQO4sTKkH2juR0VNTsug6jGUd8F/eb3k/ZV1a94xg/rr0fritMeGGU1NbgeI7A 5KevH4vbfwg9jTTsVpCQMahLpDzVAuJQIuv8WIDfGklit1KNsb/gyMql7lUTwMeC oVIsGzHma7sy4HyjqUqf7rY5oagyRYHp48fXRe/ykiXrPgdpCh5qYz2YxUrZvZW/ Rra66WGBnUV/ejLFxZasBg== Received: from phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta01.appoci.oracle.com [138.1.114.2]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 494yd8g5dn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 13 Sep 2025 07:56:41 +0000 (GMT) Received: from pps.filterd (phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 58D70Pe1019148; Sat, 13 Sep 2025 07:56:40 GMT Received: from sn4pr0501cu005.outbound.protection.outlook.com (mail-southcentralusazon11011010.outbound.protection.outlook.com [40.93.194.10]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 494y29nvm3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 13 Sep 2025 07:56:40 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=aGLiMbtk7UnqPG2QiZ93b+LYVWwGQ3yxd/2oKeOKbg0psS5c+Op1EYk0ix1JMiJE81SB/HtcaQYfj2EfUC4n9LZ7JgA6QC6o3Nz1slMTwAi0PlTd8Q57XaIJ+cKjJGvnNLeCOnIcgukXTpbnoahD5+UpAHJ3JV/LvQlRa8j+dcfGwR8dTZRB8SzLkHJVt3LdLUyymNLJgmL8iO98UbqjMRhFQo9MRGdigyamileiBp2Yvb2M5h4uh9L0qsuGIZN9yXsvaavWxrgmhVPao58qoObOgdOFgy1d0sN7b6XacPCxgVPdwaoMMoTYpMgyE7sRCSQ2vv3+d6hyFW/FKLf0bA== 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=w5j0kZ3UhnZ4UyoT+nAuRzx03i/iK2SCABNlpB7lbcs=; b=CAsl6iJQlSO+5bnvb7OX1E1x7wobgVBEOKfZihSo/74taE+q0PMLPyAPWLarLQhzqpKgU4Zdv0Mz1oVRhRXEp3MWeR0Vttqc9dpILHC/5A+0CfxhfGlqqr/Ob/YQsrmTqaAEwDSfdooxsWoLjwhZ5MR+gk+yzCVF1i0CMCLutHkn9prhfsbnhcMLfYx3PXJCSAlQx5TKiFBs5L64M3A2sOujvDNbxG0E8fw/YaB6wGaUJDNHY/bVODbN2jXbqNrt/BuEmMrx8GZFXHbaoM5sEz8Q12Y1fao+WOfBWNy8xoGjJJ5sU6N/+luaCml3mapz2kGcIR/Rfm7YJLnrf+YbNQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w5j0kZ3UhnZ4UyoT+nAuRzx03i/iK2SCABNlpB7lbcs=; b=BJ/Toiyo7DdB0RM225JpWoqU8zo0m1kHeIWWIgiApjo2dwn/gEP2ox2B3B4e1besj3X0uVeCHBVoM7Fq5XYxGYKaK+XtyHEqptQVRy3sRpxgiKzKPriX9DkwsHZKTurBOSiHpQkXx3k1XyyvhksQ0ChfWShShxx3lcsdtot1zjo= Received: from SA1PR10MB6365.namprd10.prod.outlook.com (2603:10b6:806:255::12) by SA6PR10MB8013.namprd10.prod.outlook.com (2603:10b6:806:447::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Sat, 13 Sep 2025 07:56:37 +0000 Received: from SA1PR10MB6365.namprd10.prod.outlook.com ([fe80::81bb:1fc4:37c7:a515]) by SA1PR10MB6365.namprd10.prod.outlook.com ([fe80::81bb:1fc4:37c7:a515%5]) with mapi id 15.20.9094.021; Sat, 13 Sep 2025 07:56:37 +0000 Message-ID: <0c524c2c-cbfa-4058-b360-b97cd361a190@oracle.com> Date: Sat, 13 Sep 2025 00:56:34 -0700 User-Agent: Mozilla Thunderbird Subject: Re: Unaligned access trade-offs for SFrame FRE layout To: Steven Rostedt Cc: Jens Remus , Sterling Augustine , Pavel Labath , Andrii Nakryiko , Josh Poimboeuf , Serhei Makarov , Binutils , "linux-toolchains@vger.kernel.org" References: <20250912151855.3af8c2ab@gandalf.local.home> Content-Language: en-US From: Indu Bhagat In-Reply-To: <20250912151855.3af8c2ab@gandalf.local.home> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: MW4PR03CA0272.namprd03.prod.outlook.com (2603:10b6:303:b5::7) To SA1PR10MB6365.namprd10.prod.outlook.com (2603:10b6:806:255::12) Precedence: bulk X-Mailing-List: linux-toolchains@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA1PR10MB6365:EE_|SA6PR10MB8013:EE_ X-MS-Office365-Filtering-Correlation-Id: fb1ed1e3-5602-48bd-9b12-08ddf29b10dd X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|10070799003; X-Microsoft-Antispam-Message-Info: =?utf-8?B?ODcyN3EraTIreWhvWkJ5eVNHNmNJTE5NanVyMkFEVDFRTTZkZ2FFYnovbjZR?= =?utf-8?B?Um1zZjNDbW1uK3daTmt0ZWt5Y093aDg4Ukh2a05WUVhPZ1k3WUxkSm93NUYr?= =?utf-8?B?TVhGL1BreHJuZjBVaFVXclFaZmRnMGQ2K20zY0ZhVVNUMEx6djB0ckpNWGI4?= =?utf-8?B?a3hWS1kzM3lNTEh2Uml3ai8zVUhPL1dBRHh4bEwyQU51RVJYV1lEbDJpaHIw?= =?utf-8?B?WXRTTUcrVWpRcHF0VkZIKzhTcnJaajNvcFhDdndlenJ1WnpMa1ZBSmxMTitv?= =?utf-8?B?Q0hPK3JTMmJrTjVYbmNjellOVkUvS3RNZmRXd3VLOXNKVklzMFpzdDd2bnNK?= =?utf-8?B?YXR2RXRMTElqUjRMbEhYYnVteUJuekNYWFE1RGlXQk9sajNWZThpWW1nRUps?= =?utf-8?B?NHlKME1FdGo0NjZsVy9RWU9DaFdTNXQySDZ4bHNMOFJ0N3VlSlZsOTRPa2pL?= =?utf-8?B?SnNVKzduWHUrYzVkL2ZRNDhMNEVDQzkrZVNEWWYvb09mVVhzRlltMUtlYkU1?= =?utf-8?B?Q050SGZHeVRYenBzY2tRNG1uTGtIVE4xd0hpUGhFYXEyYi9uczdJVzk1N3R4?= =?utf-8?B?alRxZXZFbTl5eGEySjVTM2Q0dEJ3eUlkdFM3SnRWcmQvaG42WjE3TXZxU1BL?= =?utf-8?B?YmhlU3JxQUYwTG9ROHMwTWtuNXJhVlhwbi84WWpBQ3AvcW5lNEd3V2trdmtJ?= =?utf-8?B?cHZOeTBtUVYzelJmWnZ0OGJzeXYySkdhbWhLcnFSZkkzdWFlNzVOQWg2V3Jy?= =?utf-8?B?Rlo0WVRjcktyVnQ1bERaWkhOdzNHQlg0NFdzNTRjRDdFa2xDMmVOQkluR1VK?= =?utf-8?B?QVBFa2xnWW01TWk4L01wVlN1dDVUZkNTVVNtV3RTYktvOEduNnErSE9uYUtz?= =?utf-8?B?eEVUMjJJTzJ1K1FQek0zeDlpSG5NOE15WEIyOEtvbElOalM1MEUxbGJHU3dv?= =?utf-8?B?dTJKMjhaWHFKRUJHK1BabmV3dXFyb29jNzBoZTV3MGU5NlFtcFgxeU8yUnBn?= =?utf-8?B?akRKODFQRnJlR2tQQ0VIM3F6SHpmNnNjQU1MV1U4TmZGa2Z0RXVkQlF5THd5?= =?utf-8?B?QlYyN0ZzTDZDaDc3ZWFtSDVhaS9ralFrYk51WDdCK1QxeEtJUisxZVZ2NHR1?= =?utf-8?B?TU1lZzJhek95bG5HTnNCZjNHK3o4RGhzOGtwQ1FlMGZmcVJ6WXN3YXZPTDd5?= =?utf-8?B?eEpaeWtRMzVYZWVsQ0lGbjdCTE4vUXpUMHN5cnQ1ZGttbGd6SFZ6RUs3OTFj?= =?utf-8?B?TlkwQjBVU0pIS1p6eVlYTjJiQU1JV0xZSTE5RWl4aEpuS08vUlBDQitTRGQ2?= =?utf-8?B?cU1QMzFKZlhmWkVhbkUvNFpicHdXWWRMYitDRWc5ZkRUamwyZVlxaDFTejdt?= =?utf-8?B?c1NCVUhhRkQ2aGpMRDhNZTlkd2ZpNlJPMDZyOEVvall5NmZwc3dNREQ4TkRG?= =?utf-8?B?VnBaTVlNcXYzVkFCeGRiU3F6cDYrcFhpK0hyOTFEM25FUVZCa0ZLTlhDWDIr?= =?utf-8?B?QUZXYjJFSnJxZnZKeS84UHNoRStzMkN4WU1iTkh2MkFYaHozTUNkb3c4VjdS?= =?utf-8?B?YmhrUlQ2dWg4ZDh2WFljZFBXeFB5SHV4bEdrcGZOQXJTaCt3a2xPN0VwT3da?= =?utf-8?B?VXJSV0w5ejVtUk9kM1BTOU45THVyNTZHTVBhRmkycnRFdXdjYVFuZEVsQ0tt?= =?utf-8?B?NFdmd2hWY0ZPYmJicXRKYStHWExnU0NJQVY2RHlmWit2QjV2K2VyMW5HZDhN?= =?utf-8?B?U1lOVVNadWdoOWZsdVpZQ1JHc0tuZ0F3WUJ1ZzUybmtJNll2aXZEbVgvSVgx?= =?utf-8?Q?ms63CvvCSNgroCzPMLCmLwTAhIi8bpF8Fgn8g=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA1PR10MB6365.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(10070799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Yk1KYzd5dGhNd1BJMWdJd2pPc2NsN2NucGtCay95N3JDck4rZ2laWkVjTHd2?= =?utf-8?B?NnRwOTkyR3lsNjR5OGEvUFRtZlJRNWFjcHROMzJ3eCtwdVBTNzJBbUdNWVFk?= =?utf-8?B?L0xmYk5ETUlIeTZlWkl0aE9RK1dJWFErWjVNaGNJRmozTDNqcE8vbEVnVVVE?= =?utf-8?B?N2JrS2swQU45Mkl2SVdZL01iR1JXN0tYT09MSlJhRGhneWh1SEFFbC9vRVBD?= =?utf-8?B?QTJrd3dXRldyRUlRK0U0VnFoOFlqY1ordUhrRFJKR2dTVGIvSXlrNHJOdXIv?= =?utf-8?B?M2w5VDJqY0FyZzdwTVhzYVRHVm9EZXNHQzI5S1NvY1A4bUhUclRMT0lOaWpu?= =?utf-8?B?WC9iZ1FkRjdQNDgwazdSVmJYZkRvTXdjSlo5T04vRjd3NlI4TnFJMVJ0SjVW?= =?utf-8?B?NnVpbGxOWFd2MWw1dDcyOWhTU0hndG9COXRWL3h3aHoyUXJyUUU4Yzl3RFRa?= =?utf-8?B?MXllZE03bFlnRm5FRnJhTWtEaDd6VEJMdk9Sa2VwbUVmbTJmT3VhUzRoWW1n?= =?utf-8?B?d0lRNXZ4NDVMM3RFVis0d204dGFyWFcrUWxSdUFqYnYvS2ZhdXFzN256NUUr?= =?utf-8?B?dXVISzExdit5Tk83UTBhU1dLMWJUZjNPNFkrRGYrNFhKcWN0WkNaWjhKNzBQ?= =?utf-8?B?cDJaMjhSODZrU001RTlNVjBFTVdLb2dTbHFwR05ObkhodFo2amEzREZtNDE5?= =?utf-8?B?RzMxUlJkVTAxNzBDTmFyQnlPQXZscmo4R2lteEpENERBRTFUV2Qrd1FYTDFE?= =?utf-8?B?a1F3d0ZjL0p0TzFjUTlmV09CNHZLMDVrMlJ3V3h1NlhUNml2cElFdUIvcGN1?= =?utf-8?B?U0xQQ2JXZHhmWUwrWWgxelVwZWltWElnQW5rREJmazl2TUJQNWZFb1QrR3pT?= =?utf-8?B?dlJLcjc3RGF1QjFhS201YUdsL1IxWHhnVHlmT0JFeFVCSklwSDBWbFZsVjdr?= =?utf-8?B?aGhSa0lVQnpTSGF2emFSRTFCeHpqT1NPT01Ia3JuTmR1aml3ZHV3QTc4QVl4?= =?utf-8?B?RGRodUNOK2ZTeXpKVGxTSWJoYVgzNUJxMEpUb3VhdTJoemt1YTZFKzdodmVk?= =?utf-8?B?Q0lrSW15NnVRMjlwSEkzMXBsK09JSzhpVDlZRDVDM2J6amJpZks0ejFDaC9X?= =?utf-8?B?RDNQZGl5bEdmanJTK0JIOC9IZHZmeGs2VnByVTlWTndibmw2cmNjSXZ6VXpQ?= =?utf-8?B?b1IzZnFBbEk2TXZzSEE0b0tucG5scktZN3BacDhNNlhXUmcwKzlkYWR0enNh?= =?utf-8?B?czFVeCtmRUd3Sm1iZ3llQ1QwaHBKRS9PU0Y5Yzd4eHFlV2llSVA4NUJsWEZq?= =?utf-8?B?RmlFN1VyUTN2b1Z4NWVMN25nTmpCKzBROUpVRzBNc0RObnlYUkpTSTNLSW1P?= =?utf-8?B?VnpnbFg2THRRVnBBWUFyQldydEFsTXR0NURQaW1mU2JKQk9SbUJJUWpra01C?= =?utf-8?B?VnUzMEFjQ2xLYzc2ODF3QUtmdXpUUU1tOTdZTmlYaFF4a291VTlLcFAzQ3oz?= =?utf-8?B?V1pJTk1VZnZoM253WlEyLzRVMzdhQk4zcjNiL0o4WnFGWFk4YnBzVmRLeGVQ?= =?utf-8?B?UEZ4TytXZ0ZheEJRZ3F2clpPVzJPUnhuYTN1cWRqZSs5bFNpZnRtY0ZhdG9V?= =?utf-8?B?QmtidFdMa2FReWQvSmxaT25QRjN2T0hBRERIa0JDZWlZV05YQUc5YlFlS0JF?= =?utf-8?B?ZWRZVHlvbnF2RWJkT1hNcXQ5aFdTUmxzLy9XaXJ6VzViMkUxOTdaQWxmeWxy?= =?utf-8?B?RWlvTlRVYWNCZzVQTWg1VEc0VjZiamlsV3ZFZHJIcUdKZjROdzZLcm9HWmxF?= =?utf-8?B?aE9XUHRkWjY0cFlYT281clp2ZEtjSlhJcThEellYRDdsdU1XNmV1YlQ4QXBT?= =?utf-8?B?cnhDcjMvSDVZUjdSN0F1TkhETFl1Si9tbDVUcDdLUEJDTzc2YzVpMjRxYm9V?= =?utf-8?B?VVphaVNPNVhSaDBkUjRBV2xhbU9CaE1tVEUxSUxZMjRSRlVwY0dCVkg0SXZO?= =?utf-8?B?eThqU081bGkwclVvOVFKaEtGaVJrTEtnL1JWTnFQNXlIbnFWbHBheUxhRnpq?= =?utf-8?B?OXJPd1N6dEl0eVU4cEpGNjZ2WEV3UXFmRThjWVpQUURIc0QxdVVCY2pkRThX?= =?utf-8?B?dk52YUlqdjNESUs2Z2RBRGZqSUpRTjdidVFPVk5XQlJxYW15bktKR3FnVkJr?= =?utf-8?Q?stL+2SbMejMD1RAIDNcGA74=3D?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: O9/IfRA1WbkW32MAzNXgWT8xBIUFdIQyDd8I1HxmB29wPbXb5kOmcdzVUZLr32wy3m9ESOKPfvy8ikFg9mOAGN+v6I1vqgJeXWq+7W8f10fGM2SiGmsXNb6kiEeduSFH20+9Jrav1F7wS3Bz1NNE4tlu431HvqtyMzJFNQ/2VWrrcN/SRgV1GfMtiKGqlq8bQvTx4AmCQW2Ydx9bIH6zMrkqu8D7WZcCGZ4pML7D0lEpo8knQVIZxU9wyhBJFobs9lnjp0lo03m86jWJHPw0hTWvVaXOmmOEswZbXdXSmQHlbvYs4QnNHfNJt5qadAQV0moVR21x3UlKS97yl6C9ae4iONyPOPMq9MtrRLRqMb1NYaiW9ZIqqa4lBCqCUoz+1X53wJUbkJKy1fyT5a6Ehk0oltbArLYQlp9sqARIIYewCPdeWSOT6QpMQuAoC5eGUaC9Q6JjO4RC1Ng3owtQm22AkP0Hdik0Cjd/bsjh9TFc8sHXmS9SMNe1SyUQnfXO8wg10TpAmxLN1s7vnKGmHw4nUSoaL+MmOKG0CRPYnLyRU8JsfILYf5sJrcpgEZfQw5zURQTQuu/bHNUSwv0hgobmxhi8C5HB9hOIrWPgET0= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: fb1ed1e3-5602-48bd-9b12-08ddf29b10dd X-MS-Exchange-CrossTenant-AuthSource: SA1PR10MB6365.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Sep 2025 07:56:37.5450 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: h4T5OYd8+NkzFZQZN0+9FQyOgLU1SRHFL4dEuaYm0zlK3HlGwlh/sb5Xb07ZVwIx39Cf/PnJYNrUdy9SiJUP7g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA6PR10MB8013 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1117,Hydra:6.1.9,FMLib:17.12.80.40 definitions=2025-09-13_02,2025-09-12_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 phishscore=0 suspectscore=0 spamscore=0 mlxscore=0 adultscore=0 bulkscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2508110000 definitions=main-2509130073 X-Proofpoint-GUID: aJNm1GxHfHifmhrvRT3dCEEZmzuj6Mwk X-Authority-Analysis: v=2.4 cv=M5RNKzws c=1 sm=1 tr=0 ts=68c523b9 cx=c_pps a=XiAAW1AwiKB2Y8Wsi+sD2Q==:117 a=XiAAW1AwiKB2Y8Wsi+sD2Q==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=yJojWOMRYYMA:10 a=GoEa3M9JfhUA:10 a=CN4tZqvHAAAA:8 a=CCpqsmhAAAAA:8 a=yPCof4ZbAAAA:8 a=-evvEY1iulD09wlvQ1EA:9 a=QEXdDO2ut3YA:10 a=mvaYkPfxIIjfemVm_FPj:22 a=ul9cdbp4aOFLsgKbc677:22 X-Proofpoint-ORIG-GUID: aJNm1GxHfHifmhrvRT3dCEEZmzuj6Mwk X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwOTEzMDAxNiBTYWx0ZWRfX/tBK9diBhuKX cgyeqyYa4p6dPSie4OO2PBBbKe1B0G1gcvcmM95xsH1hofOj9ooESdslNDhGROQBHt3Lf71oR60 jPwlA23CoW1CYGTQ6TfyGwxfLT1Jyy61XOKpyp1P9KVCSC3sIaweepBZ2K7aYUd70G2W07dW3IY jRygzOEAKMjKxvYhbomUtHcpY1+deg0GNehfnzS7209WsYMVum06EdtfAj/FFiDwoKxhlS6yncZ 1hLO4JGKwgEwyn1TYttaCpKm9bGVWi0Q6OFLD0qzLEdoo8rvOmGAwzf445xqtPAyWuJow7sCbYJ 2e4OIPzBq3hAp2rqledg+GbQMI/M9ddO+HDGVcPbm0Oa+1xNDaTmN3vXvfMOcD7iNtOX/4nDcVA DtflS4Tt On 9/12/25 12:18 PM, Steven Rostedt wrote: > On Fri, 12 Sep 2025 10:34:42 -0700 > Indu Bhagat wrote: > >> TL;DR: Thinking and experimenting a bit on the possible approaches for >> avoiding unaligned accesses in the SFrame FRE layout (in SFrame V3), I >> am not convinced that avoiding unaligned accesses for performance is >> worth it. IMO, forsaking compactness for avoiding unaligned accesses is >> not a good trade off for SFrame. >> >> Problem Statement >> On architectures such as x86_64, AArch64, and s390x, unaligned memory >> accesses are handled transparently by the hardware but incur a >> performance penalty. The objective of this analysis is to evaluate if >> these unaligned accesses can be eliminated from the SFrame FRE layout >> and if doing so provides a net performance benefit. > > I guess the question is really, is it that big of a performance hit? > > I know some others were worried about the performance, but we should look > at measurements too. Is it going to be a big enough issue in the stack > unwinding code to even notice? > I think quantifying the performance impact of unaligned accesses for stack tracing using SFrame sections will be larger experiment which will be hardware dependent.. https://lemire.me/blog/2012/05/31/data-alignment-for-speed-myth-or-reality/ It seems, for newer architectures, if the unaligned access is to the same cache line, the cycle impact is minimal. When the unaligned access crosses cache line boundary, there may be a few cycles of impact. When unaligned accesses cross page boundary, it gets noticeable. That said, I can give some static numbers from some SFrame sections on x86_64 for now. I see that across the SFrame sections for GNU Binutils binaries (-O2 binaries): - ~30% of SFrame FRE start addr across all functions are unaligned[*] - ~4% of all stack offsets are unaligned. [*] Caveat: This should not be construed to mean that 1 out of every 3 SFrame FRE start addr are unaligned. There may be functions where SFrame FRE start addr are all aligned (e.g., because they were 1-byte long). Above data is average across all functions in one binary. >> >> The central challenge is that any alternative must demonstrate a clear >> performance improvement while avoiding significant size overhead. >> Introducing "bloat" to the format to solve a potential performance issue >> is a poor trade-off. > > Correct. I would like to see performance numbers before we invest too much > time in this. > >> >> Source of unaligned accesses in SFrame FRE >> - (#1) Access to the SFrame FRE start address (sfre_start_address) >> - (#2) Access to the SFrame FRE stack offsets, This is varlen data >> tailing SFrame FRE top-level members (sfre_start_address and FRE info), >> usually interpreted as stack offsets) > > BTW, we should also look at how often are there unaligned accesses? All the > time? or just a percentage of time? If it is a percentage, what is that > percentage? > The stack offsets for an FRE are accessed once per frame (and an SFrame FRE may have an average of 2 stack offsets on x86_64). WRT FRE start addr, multiple SFrame FRE start address may need to be read until the applicable SFrame FRE is found. SFrame FREs lookup is serial. SFrame FRE start addr can be 1-byte/2-byte or 4-byte (one size chosen per function). The larger point I was trying to make was: The alternative layouts of SFrame FREs may fair worse in performance or compactness or both... So either way avoiding unaligned accesses does not look feasible with any of those approaches.. >> >> (Note that in the SFrame specification, SFrame Header, and SFrame FDE >> (function descriptor entry) have aligned accesses.) >> >> Updated notes on the various approaches and respective evaluation notes >> on the wiki page: >> https://sourceware.org/binutils/wiki/sframe/sframev3todo#Avoid_unaligned_accesses >> >> Summary of Approaches and Analysis/Notes >> Unaligned accesses may mean lower performance, but the alternative we >> pick must at least provide better performance. It is also important >> that the chosen approach does not add bloat to the format. Avoiding >> unaligned accesses at the expense of bloating up the format is not a >> good idea IMO. >> >> Approach 1a: Bucketed members >> Pros: Negligible bloat. >> Cons: 1. Writing out the FRE data is somewhat more involved. Affects >> assemblers, linkers. 2. For the common case though, accessing stack >> offsets now needs more memory accesses per FRE. This approach will not >> bring clear performance benefits; the additional complexity in SFrame >> readers and writers is not justified then either. > > Right. If this causes more cache misses or worse, more page faults, to save > from an unaligned access, I don't think it's worth it. > >> >> Approach 1b: Bucketed members with Index >> Cons: Significant bloat (~30%). > > I personally believe 30% is too much overhead. > >> >> Approach 2: De-duplicated "stack offsets" >> Pros: Will help reduce the size of SFrame sections. >> Cons: 1. SFrame FRE layout is designed to be flexible so that it can >> serve needs of new ABIs: The varlen data is interpreted as stack >> offsets on x86_64, and AArch64, but may not be the case for other ABIs. >> De-duplicating non-structured data is not meaningful. 2. Writing out the >> FRE data is quite more involved, increasing the complexity in Toolchain. > > I don't know enough to comment about the above. > >> >> Approach 3: Good old basic padding >> Cons: Significant bloat (~22%). Performance win arguable as well. > > I think 22% is also too much. > >> >> IMO, none of these approaches provide viable way to move forward. The >> proposed methods either fail to deliver the desired clear performance >> gain or introduce a significant size penalty or complexity, which is an >> unacceptable trade-off. >> >> Would like to gather inputs from the interested folks on this. Please >> take a look and chime in. Other ideas welcome. > > As stated above, I'd like to know how much of a performance benefit this > is. It may not be worth it. > > I wasn't one of the people who brought up unaligned accesses. I'd like to > hear from them to get their input. > > -- Steve