Hello together,
On 8/18/18 3:15 AM, Waiman Long wrote:
On 08/17/2018 12:45 PM, Davidlohr Bueso wrote:
Cc'ing Manfred.
On Mon, 18 Jun 2018, 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. To satisfy
the need of those users, a new boot time kernel option "ipcmni_extend"
is added to extend the IPCMNI value to 2M. This is a 64X increase which
hopefully is big enough for them.
Could you please provide more info on the need of these users and how
you came up with this new value (which just seems quite arbitrary)?
Thanks,
Davidlohr
Red Hat has a customer that is migrating from Solaris to Linux. Some of
their applications just happen to use more than 32k of shared memory
segments. I think Solaris allows up to 16M unique ID.
Yes, the amount of increase is a bit arbitrary. I was trying to balance
how many bits should be left for sequence number. Maybe I should just
take 8 more bits for ID and leave 8 bits for sequence number to match
Solaris.
- I think we should use the same numbers as Solaris.
Otherwise we later have to touch it again.
- What is the performance when using shmget() with already 10M segments
present?
- I like the new logic for updating the sequence counter.
Is there a reason why you only enable it for extended mode?
You create a rarely used codepath, and I don't understand what speaks
against switching to the 'deleted' approach for all systems.
--
Manfred
