On 02/07/2019 03:54 PM, Waiman Long wrote: > On 02/07/2019 03:08 PM, Peter Zijlstra wrote: >> On Thu, Feb 07, 2019 at 02:07:19PM -0500, Waiman Long wrote: >>> On 32-bit architectures, there aren't enough bits to hold both. >>> 64-bit architectures, however, can have enough bits to do that. For >>> x86-64, the physical address can use up to 52 bits. That is 4PB of >>> memory. That leaves 12 bits available for other use. The task structure >>> pointer is also aligned to the L1 cache size. That means another 6 bits >>> (64 bytes cacheline) will be available. Reserving 2 bits for status >>> flags, we will have 16 bits for the reader count. That can supports >>> up to (64k-1) readers. >> 64k readers sounds like a number that is fairly 'easy' to reach, esp. on >> 64bit. These are preemptible locks after all, all we need to do is get >> 64k tasks nested on enough CPUs. >> >> I'm sure there's some willing Java proglet around that spawns more than >> 64k threads just because it can. Run it on a big enough machine (ISTR >> there's a number of >1k CPU systems out there) and voila. > Yes, that can be a problem. > > One possible solution is to check if the count goes negative. If so, > fail the read lock and make the readers wait in the wait queue until the > count is in positive territory. That effectively reduces the reader > count to 15 bits, but it will avoid the overflow situation. I will try > to add that support into the next version. > > Cheers, > Longman Something like the attached patch. Cheers, Longman