[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 00/11] assorted replacement of x[mz]alloc_bytes()


  • To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Thu, 8 Apr 2021 13:57:43 +0100
  • 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-SenderADCheck; bh=R4xVG+9MFsOKftN253u73h97zGAl4zaT+SLmdHOHDR4=; b=mLo19NM1EpwG5Jsz21ZCqBxvofEHGq5fXGkzc74ofUskcARfRU+RwTeCr8Z467MJ4WmdAKxFpSlBXcz8DT/3SeU8Z/VdAyP35OOTPG5BjQNQ+5oBUrQtvkksIOHIIINS9Ffw4EpzP2ysuk2EDz0Aj9abZRT0h2J7Atd/PSJvcF28U2Cy91XH9BMTlEpXRlo+ZZid2FimfjgTWzCLFWgUKfbkrsE724xHvpgiGnYS7Jq4VtZcIJXjd9eA8M8qxhxBjQrWZtmPcc+08hgmLq9wAAPxWQ3apNHaXUmugMhuCKE6DmUPxkvCr5RjOr/CTj6+NO5xqSQDzd4lxpY6dmYj6w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IK/XWxJGqbq+djVv6o/4VI46Xq7rVKDVOrvxqUDaT1hsKnknPyhOM1WO1/roQwdLebCeAs19TKjvgmxxQ9OMcopdrCIv/OwTI6nmMYl8408qvdAJk90ry2sphN3Wb+grCSGaRv1ilPmhjg8qNnG3y+CGs/CtlNc8LEv3tQOV8HiEFBl5Z3NL65t7hr5frMhG6WRvHjuNfH/nnyOj4wA/ULkKfw8YimE5UL92yCQHl3XcPoi1BvRdYJVMiBSN/jFfCfGtF+mL/5QkGlSNtYjmROZU/jMVAMzN2pFGC21Q0OQFJVgl61pxHNYDdNZ5Z5suFBCSdNZWzIe6v2BbGfVaRA==
  • Authentication-results: esa6.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Thu, 08 Apr 2021 12:57:59 +0000
  • Ironport-hdrordr: A9a23:unuoaK0ce2DUpEw6WAMLygqjBR13eYIsi2QD101hICF9Wvez0+ izgfUW0gL1gj4NWHcm3euNIrWEXGm0z/BIyKErF/OHUBP9sGWlaLtj44zr3iH6F0TFmdJ1/Z xLN5JzANiYNzRHpO7n/Qi1FMshytGb8KauwdzT1WtpUBsCUcFdxi1SYzzrdnFebg9AGJY/Cd 647s1IuzKvdR0sH7qGL1MCWPXOoMCOqYnvZgQICwVixA6Fiz6p77CSKWnm4j41VTRTzbA+tV XUigCR3NTej9iX6D/5k1XS4ZNfhcf7xrJ4ZfCkp8AJJlzX+32VTat7XbnqhkFSnMiO7xIQnM DIs1McOa1Img7sV0WUhTeo5AX6yjYp7BbZuC2lqF/uu9bwSj5/K+cpv/MgTjLj50AtvM5x3c twtgrz3fcnbmKj7VDAzuPFWB1wmk2/rWBKq591s1VlXZYDc7gUlIQD/SpuYeQ9NRjn44MqGv QGNrCk2N9qdzqhHhXkl1V0zMfpdno+GQrueDl5huWllxJSnHx/0nICwt0eknoq5PsGOul5zt WBHaJymL5USMgKKYp7GecaWMOyTlfAWBTWLQupUBraPZBCH0iIh4/84b0z6u3vUJsUzKEqkJ CEdF9Dr2Y9d2/nFMXm5uwLzjn9BEGGGRj9wMBX4JZ0/pfmQqDwDCGFQFcy1+O9vvQ2GKTgKr SOEaMTJ8WmAXrlGI5P0QG7cYJVM2MiXMocvct+c06So/jMNpbhuoXgAbXuDYuoNQxhdnL0A3 MFUjS2Dt5H9FqXVnjxhwWUdGjqfmD54JJsAInX9+Ue0+E2R8lxmzlQrW78ytCAKDVEvKBzVl B5OqnbnqSyonTz3Wug1RQvBjNtSmJupJnwWXJDogEHd2nud6wYhtmZcWdOmF+OJhp1SdLqAB dSzm4Hv56fHti1/2QPGtinOmWVgz84v3SRVaoRnaWF+IPDdo4nCI0lHIh8Dx/CGRAwuQsCkh YCVCY0AmvkUh/+g6Ssi5IZQMvFccNnvQutKclI7VTFtUudoskrbmABXyGnVPOWhQpGfUsQun RBt4skxJaQkzemLmUyxM4iNkdXVWiRCLVaSDieaJ5sgbDtcgFoRWKsjTiX4itDI1bCxgE3vC jMPCeUcfbEDh54tmpD2qjnyl9ya16QZll9cHx8rI17G1nXo3ob657/WoODl0+qLncSyOAUNz /IJQEfJQ5j3Pib/h+YkjTqLwRq+rweesjmSJgzebDa3X2gbLCSnaYdBvlO4dJOL9b1qNIGVu qZZi6YJD71EPkSxgSQv3opURME8EUMoLfN4lnI/WK41HkwDb7uO1xgXagcOMzZwG7+RfqEua 8Jxe4djK+VCCHWZdGHw62MMGIGBRPXvGKsT+Yn7bpTprk/sbNvH5/dFRvEvUs3qikWHYPRrg c5Rq8+3ZXqfqlIVOYWczhC/lUomM+URXFb+DDeM6sbRxUVk3TfP9m1+LLGprokP12ZqGLLSC 6i2hwY282AYjCK2rEbAZ8hOGh6aEAz73J54eOJHregQTmCRqVm/FCgNGW6f6IYYK+ZGa8Iph IS2aDFo8anMw750hvXpz11P+Zn9HumW9q7BEapFfRT+9K3fXSKja3C2r/9sB7HDR+6YV8fn4 tLaAg5adlCkCAriMkP6ReJI5aH6X4Noh95+jFollnkx4ig7iP6JCh9QHzkq6QTeyJSPHiOhd nC6s6C2h3GkWN45aU=
  • Ironport-sdr: BA2Ilrn0VCn/uUt+AqwKRhylBaQDtJ9m74pwSlrXFoBMdUo3LjyCcCt3hNI0ez14AKBsfPz04w 0RniCZccdj1ZyzCu2BRTEJNG3cPzvD93kuQFqIMMoJ5V5lpFCC4fZT/dKdxD9nvrv5L3tbJKeL jMJtMRUSU8OPHYazppyHigwQ/UgChVgbuLi1J7oEgwbEUIFftXBfbOTPhPc/iBIO0+lL1DHwdB fvVqfv35+7g2Tc0pYIu/Vgb6N4uKsn89j7ag7CiN+3LXPXaknZJNsBeu/aYu7EZM1Fb6YUrj/s gu4=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 08/04/2021 13:13, Jan Beulich wrote:
> In the long run I think we want to do away with these type-unsafe
> interfaces, the more that they also request (typically) excess
> alignment. This series of entirely independent patches is
> eliminating the instances where it's relatively clear that they're
> not just "blob" allocations.
>
>
> 03: x86/MCE: avoid effectively open-coding xmalloc_array()
> 04: x86/HVM: avoid effectively open-coding xmalloc_array()
> 05: x86/oprofile: avoid effectively open-coding xmalloc_array()
> 06: x86/IRQ: avoid over-alignment in alloc_pirq_struct()
> 07: EFI/runtime: avoid effectively open-coding xmalloc_array()
> 08: hypfs: avoid effectively open-coding xzalloc_array()
> 10: video/lfb: avoid effectively open-coding xzalloc_array()

The flex conversions are fine, but I am unconvinced by argument for
interchanging array() and bytes().

The cacheline size is 64 bytes, and the minimum allocation size is 16,
plus a bhdr overhead of 32 bytes, so you're already at most of a
cacheline for a nominally-zero sized allocation.

There can however be a severe penalty from cacheline sharing, which is
why the bytes() form does have a minimum alignment.  There is one
xmalloc heap shared across the entire system, so you've got no idea what
might be sharing the same cache line for sub-line allocations.

We should not support sub-line allocations IMO.  The savings is a
handful of bytes at best, and some horrible performance cliffs to
avoid.  People running virtualisation are not going to be ram
constrained to the order of a few bytes.

For small allocations which don't require specific alignment, then
putting bhdr and the allocation in the same line is fine (if we don't do
this already), but we shouldn't be in the position of having two bhdr's
in the same cache line, even if there are plenty of single-byte
allocations in the theoretical worst case.

~Andrew




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.