Received-SPF: pass (google.com: domain of linux-kernel+bounces-73495-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
From: Michael Kelley <mhklinux@outlook.com>
To: Boqun Feng <boqun.feng@gmail.com>, Saurabh Singh Sengar
	<ssengar@linux.microsoft.com>
CC: "haiyangz@microsoft.com" <haiyangz@microsoft.com>, "wei.liu@kernel.org"
	<wei.liu@kernel.org>, "decui@microsoft.com" <decui@microsoft.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>
Subject: RE: [PATCH 1/1] Drivers: hv: vmbus: Calculate ring buffer size for
 more efficient use of memory
Thread-Topic: [PATCH 1/1] Drivers: hv: vmbus: Calculate ring buffer size for
 more efficient use of memory
Thread-Index: AQHaXkS5EPrFeM+bCUuIdPJ7ndDWZrESz/SAgAC4IYCAAAQbgA==
Date: Tue, 20 Feb 2024 18:15:52 +0000
Message-ID:
 <SN6PR02MB4157CF4A309971B21296D465D4502@SN6PR02MB4157.namprd02.prod.outlook.com>
References: <20240213061959.782110-1-mhklinux@outlook.com>
 <20240220063007.GA17584@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
 <ZdThZUUmGhY2shrX@boqun-archlinux>
In-Reply-To: <ZdThZUUmGhY2shrX@boqun-archlinux>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?EuEWnoe3axsNIQpvJIRE2ryDyF3+nJmBJpXiqFHJaR/a6G3yYpAOiZ6Cw6Yy?=
 =?us-ascii?Q?g2QtVu6gqLTKXDxMO/yOgSBWEKs0BS2G0mL9t26gpcdrUaF5Q3ndJON8Mj1k?=
 =?us-ascii?Q?MqOBTWo3WBy3ceIXcwNj38uAl3tmoc4YQqa3C7AG1+2lOtnzFGH6InuDJ2mh?=
 =?us-ascii?Q?uG1L73KqodJ+fPf4XE7N/cRVO8WWG3d8SyshHE0kdPteuA5QRSsYYt21YQm5?=
 =?us-ascii?Q?6xTB8bD+xW8OAhlFQ8gErhs/pgd3vqLSc54Q48abqip/v4R/3GPV1ZfizTUp?=
 =?us-ascii?Q?ExrAVGQf2+uho50Pp5S61YHDgkGZzwDN8eQL1c7IabRiXpBuS5wZQr8RyCDo?=
 =?us-ascii?Q?QGT2K9OK2XnWV73cIJ6R5mXpanm4QGF91OgAr7hqt4fLdMmEy6IOpz3JBIIM?=
 =?us-ascii?Q?H78OsCviJ4wX/x4MsW0ndwZtsuEizCmVrpRlCXJLqQpLVgKn1qUTVRB46TPb?=
 =?us-ascii?Q?j+8MaXFYcqe7EpEzSl5uXwq5EQJSpi0J2lcc08o/WI1PwvtVwVTr71mXiDGh?=
 =?us-ascii?Q?Az1jp8PufpuZc5tFUmQDVSici0oT+hIx1UR5LX/IET1ZWoyp4JsOka9SKetr?=
 =?us-ascii?Q?xipblWYZ5yqrHZtJ0AJMBvzVyOQoXsR0P5QZQZeinsyPAjyEEGD+ksNXo8PI?=
 =?us-ascii?Q?CzzHcawfQALn9FK7dUFR2+0VkGFlLqtZRbIjGdcr1BuLijh0/7iREwRy48Fr?=
 =?us-ascii?Q?Q59H6GDrImdL8/QeVoCtgOqQGy6jydbhv3sT4uH0T6FKrp9ntUwficswZkUQ?=
 =?us-ascii?Q?1TQn5FU1GmKJ/tl6VI2pEjGTaebBLwbkBEQW6Q6orrAYGwuoPApVG+byzpJX?=
 =?us-ascii?Q?F7VTn6JHe+5rYboTQXFrYEt8GC4+5UDm81LjQCf+llhRe/J07fIMGEP9B9As?=
 =?us-ascii?Q?YtGxg/19pA+mJTzwxVWIdBsFG9S4KGsWHd3p4yQ2TqYWWvXBuZ0Gy9RKNfqF?=
 =?us-ascii?Q?JItPhypEDFxVvv/+SNjruZsnYmjeQBVA9PFMD06kBUUvQsH1mQkeaTeIWi/z?=
 =?us-ascii?Q?5ei6uUbsnDaQEHleFPyanTmLkyaXGlcB1WqR0fiACTdVgwiCBcFL60Yjsf0O?=
 =?us-ascii?Q?FR01krbqFTz5z06eX+XNgkS/HK2SGfZKLqXLltCHuNZ9GnZAcv+eWT3zHF8J?=
 =?us-ascii?Q?gHojZ4LtwUi8G/LS/cFlpQT6j5v7L8eZugkH5YiB/DIfq8tbsqFlw9uaNT/v?=
 =?us-ascii?Q?7JVO8XsoHgwPZx3wR24a3sLFOhN43JOLqk1dRg=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4157.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 58409dff-ba0b-49e1-aaff-08dc323ff98e
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2024 18:15:53.0454
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR02MB10121

From: Boqun Feng <boqun.feng@gmail.com> Sent: Tuesday, February 20, 2024 9:=
29 AM
>=20
> On Mon, Feb 19, 2024 at 10:30:07PM -0800, Saurabh Singh Sengar wrote:
> > On Mon, Feb 12, 2024 at 10:19:59PM -0800, mhkelley58@gmail.com wrote:
> > > From: Michael Kelley <mhklinux@outlook.com>
> > >
> > > The VMBUS_RING_SIZE macro adds space for a ring buffer header to the
> > > requested ring buffer size.  The header size is always 1 page, and so
> > > its size varies based on the PAGE_SIZE for which the kernel is built.
> > > If the requested ring buffer size is a large power-of-2 size and the =
header
> > > size is small, the resulting size is inefficient in its use of memory=
.
> > > For example, a 512 Kbyte ring buffer with a 4 Kbyte page size results=
 in
> > > a 516 Kbyte allocation, which is rounded to up 1 Mbyte by the memory
> > > allocator, and wastes 508 Kbytes of memory.
> > >
> > > In such situations, the exact size of the ring buffer isn't that impo=
rtant,
> > > and it's OK to allocate the 4 Kbyte header at the beginning of the 51=
2
> > > Kbytes, leaving the ring buffer itself with just 508 Kbytes. The memo=
ry
> > > allocation can be 512 Kbytes instead of 1 Mbyte and nothing is wasted=
.
> > >
> > > Update VMBUS_RING_SIZE to implement this approach for "large" ring bu=
ffer
> > > sizes.  "Large" is somewhat arbitrarily defined as 8 times the size o=
f
> > > the ring buffer header (which is of size PAGE_SIZE).  For example, fo=
r
> > > 4 Kbyte PAGE_SIZE, ring buffers of 32 Kbytes and larger use the first
> > > 4 Kbytes as the ring buffer header.  For 64 Kbyte PAGE_SIZE, ring buf=
fers
> > > of 512 Kbytes and larger use the first 64 Kbytes as the ring buffer
> > > header.  In both cases, smaller sizes add space for the header so
> > > the ring size isn't reduced too much by using part of the space for
> > > the header.  For example, with a 64 Kbyte page size, we don't want
> > > a 128 Kbyte ring buffer to be reduced to 64 Kbytes by allocating half
> > > of the space for the header.  In such a case, the memory allocation
> > > is less efficient, but it's the best that can be done.
> > >
> > > Fixes: c1135c7fd0e9 ("Drivers: hv: vmbus: Introduce types of GPADL")
> > > Signed-off-by: Michael Kelley <mhklinux@outlook.com>
> > > ---
> > >  include/linux/hyperv.h | 22 +++++++++++++++++++++-
> > >  1 file changed, 21 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
> > > index 2b00faf98017..6ef0557b4bff 100644
> > > --- a/include/linux/hyperv.h
> > > +++ b/include/linux/hyperv.h
> > > @@ -164,8 +164,28 @@ struct hv_ring_buffer {
> > >  	u8 buffer[];
> > >  } __packed;
> > >
> > > +
> > > +/*
> > > + * If the requested ring buffer size is at least 8 times the size of=
 the
> > > + * header, steal space from the ring buffer for the header. Otherwis=
e, add
> > > + * space for the header so that is doesn't take too much of the ring=
 buffer
> > > + * space.
> > > + *
> > > + * The factor of 8 is somewhat arbitrary. The goal is to prevent add=
ing a
> > > + * relatively small header (4 Kbytes on x86) to a large-ish power-of=
-2 ring
> > > + * buffer size (such as 128 Kbytes) and so end up making a nearly tw=
ice as
> > > + * large allocation that will be almost half wasted. As a contrastin=
g example,
> > > + * on ARM64 with 64 Kbyte page size, we don't want to take 64 Kbytes=
 for the
> > > + * header from a 128 Kbyte allocation, leaving only 64 Kbytes for th=
e ring.
> > > + * In this latter case, we must add 64 Kbytes for the header and not=
 worry
> > > + * about what's wasted.
> > > + */
> > > +#define VMBUS_HEADER_ADJ(payload_sz) \
> > > +	((payload_sz) >=3D  8 * sizeof(struct hv_ring_buffer) ? \
> > > +	0 : sizeof(struct hv_ring_buffer))
> > > +
> > >  /* Calculate the proper size of a ringbuffer, it must be page-aligne=
d */
> > > -#define VMBUS_RING_SIZE(payload_sz) PAGE_ALIGN(sizeof(struct hv_ring=
_buffer) + \
> > > +#define VMBUS_RING_SIZE(payload_sz) PAGE_ALIGN(VMBUS_HEADER_ADJ(payl=
oad_sz) + \
> > >  					       (payload_sz))
>=20
> I generally see the point of this patch, however, it changes the
> semantics of VMBUS_RING_SIZE() (similiar as Saurabh mentioned below),
> before VMBUS_RING_SIZE() will give you a ring buffer size which has at
> least "payload_sz" bytes, but after the change, you may not get "enough"
> bytes for the vmbus ring buffer.

Storvsc and netvsc were previously not using VMBUS_RING_SIZE(),
so space for the ring buffer header was already being "stolen" from
the specified ring size.  But if this new version of VMBUS_RING_SIZE()
still allows the ring buffer header space to be "stolen" from the
large-ish ring buffers, I don't see that as a problem.  The ring buffer
sizes have always been a swag value for the low-speed devices with
small ring buffers.  For the high-speed devices (netvsc and storvsc)
the ring buffer sizes have been somewhat determined by perf
measurements, but the ring buffers are much bigger, so stealing
a little bit of space doesn't have any noticeable effect.  Even with
the perf measurements, the sizes aren't very exact. Performance
just isn't sensitive to the size of the ring buffer except at a gross level=
.

>=20
> One cause of the waste memory is using alloc_pages() to get physical
> continuous, however, after a quick look into GPADL, looks like it also
> supports uncontinuous pages. Maybe that's the longer-term solution?

Yes, that seems like a desirable long-term solution.  While the GPADL
code handles vmalloc memory correctly (because the netvsc send and
receive buffers are vmalloc memory), hv_ringbuffer_init() assumes
physically contiguous memory.  It would need to use vmalloc_to_page()
in building the pages_wraparound array instead of just indexing into
the struct page array.  But that's an easy fix.  Another problem is the
uio_hv_generic.c driver, where hv_uio_ring_mmap() assumes a physically
contiguous ring. Maybe there's a straightforward way to fix it as well,
but it isn't immediately obvious to me.

Using vmalloc memory for ring buffers has another benefit as well.
Today, adding a new NIC to a VM that has been running for a while
could fail because of not being able to allocate 1 Mbyte contiguous
memory for the ring buffers used by each VMBus channel.  There
could be plenty of memory available, but fragmentation could prevent
getting 1 Mbyte contiguous.  Using vmalloc'ed ring buffers would
solve this problem.

Michael

>=20
> Regards,
> Boqun
>=20
> > >
> > >  struct hv_ring_buffer_info {
> >
> > Thanks for the patch.
> > It's worth noting that this will affect the size of ringbuffer calculat=
ion for
> > some of the drivers: netvsc, storvsc_drv, hid-hyperv, and hyperv-keyboa=
rd.c.
> > It will be nice to have this comment added in commit for future referen=
ce.
> >
> > Looks a good improvement to me,
> > Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com>
> >
> > > --
> > > 2.25.1
> > >