Received-SPF: pass (google.com: domain of linux-kernel+bounces-87292-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Message-ID: <f17da20f-4379-4dc6-b988-cb3a07f4aa6f@amd.com>
Date: Thu, 29 Feb 2024 12:28:45 -0600
User-Agent: Mozilla Thunderbird
Subject: [PATCH] x86/mce: Dynamically size space for machine check records
To: Tony Luck <tony.luck@intel.com>, Borislav Petkov <bp@alien8.de>
Cc: "Mehta, Sohil" <sohil.mehta@intel.com>, "x86@kernel.org"
 <x86@kernel.org>, "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 "yazen.ghannam@amd.com" <yazen.ghannam@amd.com>,
 Avadhut Naik <avadhut.naik@amd.com>
References: <SJ1PR11MB60830AF35FA89C7869B8C11EFC482@SJ1PR11MB6083.namprd11.prod.outlook.com>
 <20240212191401.GLZcpt-XHFqPg3cDw-@fat_crate.local>
 <SJ1PR11MB6083C60D7584B02E9CAF19D5FC482@SJ1PR11MB6083.namprd11.prod.outlook.com>
 <ZcqPhVO_DtD2x5N7@agluck-desk3>
 <20240212220833.GQZcqW4WxKH34i-oBR@fat_crate.local>
 <20240212221913.GRZcqZYRd6EPTTnN97@fat_crate.local>
 <20240212224220.GSZcqezMhPojxvIcvO@fat_crate.local>
 <Zd--PJp-NbXGrb39@agluck-desk3>
 <8ee24cad-e9b8-4321-aad4-9a9ba4f8b7b6@amd.com>
 <20240229083951.GAZeBC1yS3MPonWwKv@fat_crate.local>
 <ZeDDLLQWPyyZve_s@agluck-desk3>
Content-Language: en-US
From: "Naik, Avadhut" <avadnaik@amd.com>
In-Reply-To: <ZeDDLLQWPyyZve_s@agluck-desk3>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?OFJKaXdubFdIdzJUOXlnTlR1bi9TN1pHY2tRTTFQcTROcXNucmlsQlFHUXF2?=
 =?utf-8?B?aFZFdUIrQVJINHZhL1BGdEZmdHgrb0RtdjF3d1dqemZiWThsbG1mcUpIcitI?=
 =?utf-8?B?dUQ5RkszM1NTV1U3aFRKeHNpNmRaWTMrbUQvNktHUmRwdW0wZldQeGdBS1VK?=
 =?utf-8?B?a0d3KzJvRkJPOXdzK1FMc2V0WE1LT0dHOS9PemZCb0NGOUNHN2dEcGRXZHd4?=
 =?utf-8?B?M29DendVWDI1NHp2dk5STkQxYjBxcHA4UnhFVDF1MXNvMGVaUWU0ZkVFdmJY?=
 =?utf-8?B?cG9wZURhOFZXNEZvdkQzWXNHd1FKcDkyVExUZjA2NGJJaVFHQ1ExaVV0aW5E?=
 =?utf-8?B?ejZJa1RFQWc4RVdQL04vNVpHVnA5QWFIZi9jem1PcDJ0QWQ2aUZpZStkWjNt?=
 =?utf-8?B?YWoxTklOQWNmdUNaQTdBdXphQkxQY0hHYnRJY2Q3cjA3dmNRMVlJeU53SCt4?=
 =?utf-8?B?MlRCc25oa2Zwc0VXTXFEenBPekczVE9oQTNnNDJSUm8weUpvVXk0SjlsQkFV?=
 =?utf-8?B?RUxJRTg0ZWJIdEQ3bFJtTUFTdlhOcnM2VjgwSnpZS1BhVHNObzZNWDdGUjBs?=
 =?utf-8?B?WjFwaC9kZ2tDQlZhdGNnUFp6NWsvMFhPbXk0akpaVThXMG9PZ3Juck1vVXB6?=
 =?utf-8?B?YlFNYVVOTEc5Nzc1cVF6ekpMaVQzOHgrOUFSMkR4WXBLK1c0UU1OT0t1SDBS?=
 =?utf-8?B?UzdpbFY4R1lqNW5kUmpPczFzcnVwUHd4dTIxOTdkaXVZWStsSVhGcm1BbEZ1?=
 =?utf-8?B?TkJRb29NdFovTmR2QkltUjJOcXkwdmhMUjJrM2loZ01UdmlsQmx1cEhXcDNa?=
 =?utf-8?B?ejlmTnpnTlJ1aWRzMjNGWnhMUWd3Z1FBbE5MTWl2S3V1KzRrdzgzUkp0OHlQ?=
 =?utf-8?B?aHJ2WmVpd3BFMGhtc1YwZzJURHZHS0NWejh6UE9yZmFQbmNKamF1ODNZeUJu?=
 =?utf-8?B?RnYvMk9UUzNXbTRleG9CQjJEeS9oYW1NMzExcWNPSGRGU2FnbCtpaGJOMW0w?=
 =?utf-8?B?ZmJZQjh4RVdEbXJZOWFhVGFsajFncFpNcW0xUDZSOWpMR1JxY29DbEg1YkZ3?=
 =?utf-8?B?a2V0ZHdTdExDUlVYSk5QUjcrRjJacWlBN1FUU1FSWThtVkoxMVhEa0xXSjQ3?=
 =?utf-8?B?UGVWcXROR1l6WW1qeFM1ZnM0MmxRN3dQTkNkUFV6aVp6WlRSUEZONVBZdDdF?=
 =?utf-8?B?QWJFUzR5SmVrK21Dd2lMUWhEcDFOc1d6TTY5aElWSmIvWmQrbW9QQXRqMVJL?=
 =?utf-8?B?cWxJc0pnWnQ2QUxuellFZTQ4cGVRN09ueG04UWFkUnk5QVBSVS9lMlExWkNS?=
 =?utf-8?B?cTU4czZKZ2lWV21aUHdDRUdxaU9KamJLWEhHR0VyYkNYdmRZcDl5ZVRPQmdW?=
 =?utf-8?B?TzY0K3M5OHI0cjBIbmE2RytWTHJEWFFhS1htUlc5MklmclRySkYwWEVCTEJm?=
 =?utf-8?B?ZHFJa0tXQ3pkY1JhY0w3bUpPTUNTejEyb2RWczZXYjVlL0oyWXhDYjZQckQw?=
 =?utf-8?B?bEtOaC8xV21VNEJld2t1UWlRdTgwRjVTUDFDQXBuTkhaQ0YzeGh6SlZ6WEMw?=
 =?utf-8?B?WFpyeGoxRlFMdm16R3ZBaHkrWnNnb2JTL1pxTml2bGlFUlNvcUtkaTR4KzF2?=
 =?utf-8?B?REpjMnAxTEhXN0E2c1htTnROdFAzREx2Y1kwWldTT0hML05NRWVUdUYxb1RP?=
 =?utf-8?B?SFhmQmptK2RIdXdXTTkxcS92dXI2aFpXSFJoaFliK2YxSE9aMmV6eHAyV1hE?=
 =?utf-8?B?SGNCU2s2UklJK0Y3RTRTMElCMzVJK2RWNnkyL3N1ZDlsbUt0ai82dSszakpv?=
 =?utf-8?B?RmlOY2xCRUd0RzBkbGEyUUQ5NnJFcVBUSHVHL3hyaDU0Yk9mSUNQRE8rdHlL?=
 =?utf-8?B?WXdEMHQ0NUtpbGR2SHpUMGVyelB0ZXlwdXorWFUvRGpiVkw2MEtpQUhXNEkz?=
 =?utf-8?B?TjdMYzg1ekI3RlRneDhjaDJCYUI0Y05ycUVHSm5nUjdTNTllbXRhTXpieG55?=
 =?utf-8?B?NFBvUGkrbE4vbW43ZWRrQ1FhUktXY1ByTFBzMWMvR3hmRHUzRC9ldGI4eDJ6?=
 =?utf-8?B?MkVOVUt5SVB4MUNTTHp4eGlFa28ydWxCUWlVeWpacmJFdmp5VWcxcGRkOXVW?=
 =?utf-8?Q?95CyTahCK36Vgrfr10dzUUqsE?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b991dc4d-48c8-4d9f-47a8-08dc39544496
X-MS-Exchange-CrossTenant-AuthSource: CH3PR12MB8403.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Feb 2024 18:28:47.2722
 (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: AklhPD6s9f2fIWMYz30z2z7zXWrAmlR4uaAJ4tc8cZjSSKg4ETf9OnugazbNctnCJ8ba71JByAaT5bp4wdqqwg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8916


On 2/29/2024 11:47, Tony Luck wrote:
> On Thu, Feb 29, 2024 at 09:39:51AM +0100, Borislav Petkov wrote:
>> On Thu, Feb 29, 2024 at 12:42:38AM -0600, Naik, Avadhut wrote:
>>> Somewhat confused here. Weren't we also exploring ways to avoid
>>> duplicate records from being added to the genpool? Has something
>>> changed in that regard?
>>
>> You can always send patches proposing how *you* think this duplicate
>> elimination should look like and we can talk. :)
>>
>> I don't think anyone would mind it if done properly but first you'd need
>> a real-life use case. As in, do we log sooo many duplicates such that
>> we'd want to dedup?
> 
> There are definitly cases where dedup will not help. If a row fails in a
> DIMM there will be a flood of correctable errors with different addresses
> (depending on number of channels in the interleave schema for a system
> this may be dozens or hundreds of distinct addresses).
> 
> Same for other failures in structures like column and rank.
> 

Wouldn't having dedup actually increase the time we spend #MC context?
Comparing the new MCE record against each existing record in the
genpool.

AFAIK, MCEs cannot be nested. Correct me if I am wrong here.

In a flood situation, like the one described above, that is exactly
what may happen: An MCE coming in while the dedup mechanism is
underway (in #MC context).

-- 
Thanks,
Avadhut Naik