Thread (52 messages) 52 messages, 11 authors, 2019-12-08

Re: [RFC PATCH 04/10] pipe: Use head and tail pointers for the ring, not cursor and length [ver #2]

From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date: 2019-10-30 20:35:19
Also in: keyrings, linux-api, linux-block, linux-fsdevel, linux-usb, lkml

On 30/10/2019 17.19, Ilya Dryomov wrote:
On Thu, Oct 24, 2019 at 11:49 AM David Howells [off-list ref] wrote:
quoted
 /*
- * We use a start+len construction, which provides full use of the
- * allocated memory.
- * -- Florian Coosmann (FGC)
- *
+ * We use head and tail indices that aren't masked off, except at the point of
+ * dereference, but rather they're allowed to wrap naturally.  This means there
+ * isn't a dead spot in the buffer, provided the ring size < INT_MAX.
+ * -- David Howells 2019-09-23.
Hi David,

Is "ring size < INT_MAX" constraint correct?
No. As long as one always uses a[idx % size] to access the array, the
only requirement is that size is representable in an unsigned int. Then
because one also wants to do the % using simple bitmasking, that further
restricts one to sizes that are a power of 2, so the end result is that
the max size is 2^31 (aka INT_MAX+1).
I've never had to implement this free running indices scheme, but
the way I've always visualized it is that the top bit of the index is
used as a lap (as in a race) indicator, leaving 31 bits to work with
(in case of unsigned ints).  Should that be

  ring size <= 2^31

or more precisely

  ring size is a power of two <= 2^31
Exactly. But it's kind of moot since the ring size would never be
allowed to grow anywhere near that.

Rasmus
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help