On Mon, Nov 05, 2018 at 10:43:43AM -0500, Waiman Long wrote: > The maximum number of unique System V IPC identifiers was limited to > 32k. That limit should be big enough for most use cases. > > However, there are some users out there requesting for more, especially > those that are migrating from Solaris which uses 24 bits for unique > identifiers. To satisfy the need of those users, a new boot time kernel > option "ipcmni_extend" is added to extend the IPCMNI value to 8M. This > is a 256X increase which hopefully is big enough for them. Why go to 23 bits when people are coming from systems with 24 bits? Let's just go to 24 bits. This happens to fit well with the underlying data structure which uses 6 bits per layer of the tree. > The use of this new option will change the pattern of the IPC identifiers > returned by functions like shmget(2). An application that depends on > such pattern may not work properly. So it should only be used if the > users really need more than 32k of unique IPC numbers. Are there applications out there that rely on the internal structure of the IPC identifiers?! How about scrapping all this and just doing the following: Allocate 24 bits of the ID cyclically. Increment the top 7 bits of the ID every time the cursor wraps. That's not going to give us a perfect progression from 0-2 billion, because it'll skip the ones in use. But it'll ensure the ID isn't reused particularly quickly unless the application is really using millions of IDs.
