On 11/06/2018 08:20 AM, Matthew Wilcox wrote: > 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. Sure. I can move it up to 24 bits leave 7 bits for the sequence number. > >> 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?! That is a question that may not have a clear answer. Most applications won't do that, but there are always some outliners that do crazy thing. So you never know for sure. > > 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. Eric Biederman had sent out a patch somewhat like that before. Again, there is a slight chance that it may break existing applications. So the question is whether we are willing to take the risk. I won't mind if upstream decide to go this route. Cheers, Longman
