[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: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Thu, 12 Jan 2023 10:31:58 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=a9pvGAc+QyvPB3mISkj/GXnby0SbnQtT1mzcmSy/Roo=; b=U5eCemof/9B3Df1+yB+bkhRbtam2OXSweaSmtraTj3suPmtkH/D9+eEgvBWXqxPpl64piVvaZiPgeEkMBXCgVQ4P91MPZnBRkuknsfG4PbvjbHfNj5bER78+BuIgNaGdCHHJGhSRp1kbu3Pff6dg2bpU+lWDZRZei7h+YF/7FekpSUxirlOjrYTj1P7/uGLV/0DUrjQjViL+NqhIOmO1hssgfxioR5mCAhw3bND7Mc5NIx7Ob+KuPOO9VABsw9YSsfe426C75rzYMSmS3ve8etdmZK3mM/7oAgpoF0606StzQvFVWliWXXkah0iUGU3VDMvnrtZhqykYS4TBN2S2Mg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Osx8vA9Bp1r+tE6tz+0TdmGvg5XsdRLiLM9wbstZX6/CGJkv10ocZPySuEks4YnaxEpbTx06gOAK4zJZU5dDRNeWbv/oPb+5pXNsM/krSnsDwQNYc8SoWK6PuFwTvQRFDhBybTKMGns4zgEC/cF/mGEKMrlzHX54wewSvgQUHIrxhf4v5UmHtU0ZQ70gvL2rI2fi7axesvCvnDnjlSVGARUh4hgPMrEwuBILVXarO4/4BHvx1t6iNMpYcXv2icqAwhidALw0VEPxi9C1V+wljFmF/+mPC1nRt21kzis3nyrN7RE7VKLKwNOqJ+FcRsBfJ/ih+IJ97pP+s8SjmFZ0hQ==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, "Tim (Xen.org)" <tim@xxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Thu, 12 Jan 2023 09:32:08 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 12.01.2023 01:02, Andrew Cooper wrote:
> 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.
Without optimization whether an inline function is actually inlined is
unclear. When it is, what register (or stack slot) an argument is in is
simply unknown. When it is made an out-of-line function, a compiler may
very well spill register arguments to the stack first thing, just to
make all arguments (whatsoever, i.e. not just in this function) be
consistently in memory.
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>
> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Thanks.
Jan
|
