[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 7/9] x86/shadow: reduce effort of hash calculation
- To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
- Date: Thu, 12 Jan 2023 00:02:24 +0000
- Accept-language: en-GB, en-US
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=c3iDwnezfMF+ULW9BNrpEmhodULbQKYQwOVb7MiOsC8=; b=GK6FcTleryCOEQZtvKX3dbEOde2B6dVCRvwSKBAVbggtWzqagsoHwvwiSUQAZs3JY8BSQjgNgUV+HMs/mfV89b6DRuoS6QZwxlIk9Xvdw5xHnb9hddT/NSqjQEVjq4Q6bxAJVDmbRzU9zO0rX+quxdznoYmltB6cO+z1aDsRIRovDfuI0di+7ny31iND9rtWYyAw/+msj0mBcLFGrfAOihW4VrVR9VnyVJkTwFBlwdz++n4RE6aIpla9AH2HZWd/ikPCQVwtaKzqUmbrKtFhXzClkDuwjtisPJFGbaYsifhD29W+CfYkNV1uLLW0k8ZCb9nW6fAUninvKXf2wZ99GQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hBxTqiNseKxi3Rb3bHnLcJnmemaAW6Vy14J0lgBniSDNKEY8Eia5I9kb7Biq2iK6X5wuL4NkdlGbNeY8Li2IaE2Pa6iyxmc6fKT5itA5H8p4Z48pPiU4hxxNNQZsSu88ZpbuTpx3CCDUuaRgmNSe0H3smchguFCj63rS5DUWYGjOl3vYKbLMT6ox6Sp6au8ZnWo1F5GhKUg61pv5vqQa5OfMVoKeKydeYMBNBKctQVLcRlugFAWdDJJAna+axp8bz0F11fK9xv2FVgpdoalw//cfg/DKWzXXGCEdepxlguffLH9UEe8MjeJKbzGlItSSfUGMRsVISvZb+nmEkc25aQ==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, "Tim (Xen.org)" <tim@xxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxx>
- Delivery-date: Thu, 12 Jan 2023 00:02:36 +0000
- Ironport-data: A9a23:R+DA36P2BGaixafvrR2UlsFynXyQoLVcMsEvi/4bfWQNrUok1zdVz DcfDDyHafeOZjOgfo12YY3jpxgAuJOGndNnTQto+SlhQUwRpJueD7x1DKtS0wC6dZSfER09v 63yTvGacajYm1eF/k/F3oDJ9CU6jufQA+KmU4YoAwgpLSd8UiAtlBl/rOAwh49skLCRDhiE/ Nj/uKUzAnf8s9JPGj9SuvzrRC9H5qyo42tB5wVmPpingXeF/5UrJMNHTU2OByOQrrl8RoaSW +vFxbelyWLVlz9F5gSNy+uTnuUiG9Y+DCDW4pZkc/HKbitq/0Te5p0TJvsEAXq7vh3S9zxHJ HehgrTrIeshFvWkdO3wyHC0GQkmVUFN0OevzXRSLaV/ZqAJGpfh66wGMa04AWEX0sdPGVlu1 /EpEwIuaReZl9uw0oqWTNA506zPLOGzVG8ekldJ6GiBSNMZG9XESaiM4sJE1jAtgMwIBezZe 8cSdTtoalLHfgFLPVAUTpk5mY9EhFGmK2Ee9A3T+PdxujCMpOBy+OGF3N79U9qGX8hK2G2fo XrL5T/RCRAGLt2PjzGC9xpAg8eex3mjCNtPSNVU8NZm2Qy06DYzVSYncmedqsW7kFyGBtx2f hl8Fi0G6PJaGFaQZtv3UgC8oXWElgUBQNcWGOo/gCmdx6yR7wuHC2wsSj9adMdgpMIwXSYt1 FKCg5XuHzMHmKKRYWKQ8PGTtzzaETQUKEcSaClCShEKi+QPu6k2hxPLC9N8Sqi8i4StHSmqm mjV6i8jm78UkMgHkb2h+kzKiC6toZ6PSRMp4gLQXSSu6QYRiJOZWrFEIGPztZ5oRLt1hHHb1 JTYs6ByNNwzMKw=
- Ironport-hdrordr: A9a23:AxAW0Kxvakbs1UI523JmKrPw1r1zdoMgy1knxilNoHxuH/BwWf rPoB17726RtN91YhsdcL+7V5VoLUmzyXcX2/h1AV7BZniEhILAFugLgbcKqweKJ8SUzJ8+6U 4PSclD4N2bNykGsS75ijPIb+rJFrO8gd+VbeS19QYScelzAZsQiDuQkmygYzZLrA8tP+teKL OsovBpihCHYnotYsGyFhA+LpL+T42iruOeXfYebSRXkDWzsQ==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHZJcSKbn2Oy+OF1EuP+6uJ3eHPoq6Z5sMA
- Thread-topic: [PATCH v2 7/9] x86/shadow: reduce effort of hash calculation
On 11/01/2023 1:56 pm, Jan Beulich wrote:
> The "n" input is a GFN/MFN value and hence bounded by the physical
> address bits in use on a system. The hash quality won't improve by also
> including the upper always-zero bits in the calculation. To keep things
> as compile-time-constant as they were before, use PADDR_BITS (not
> paddr_bits) for loop bounding. This reduces loop iterations from 8 to 5.
>
> While there also drop the unnecessary conversion to an array of unsigned
> char, moving the value off the stack altogether (at least with
> optimization enabled).
I'm not sure this final bit in brackets is relevant. It wouldn't be on
the stack without optimisations either, because ABI-wise, it will be in
%rsi.
I'd just drop it.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
|
