On 08/16/13 02:38, Ivan Voras wrote:
>> We have a single-writer / multiple-readers lock on *any particular byte*
>> of a vnode. The rangelock code is what keeps track of this, and the
>> locking contention I was reducing was in the rangelock bookkeeping.
>
> So, for example, if multiple processes
> We have a single-writer / multiple-readers lock on *any particular byte*
> of a vnode. The rangelock code is what keeps track of this, and the
> locking contention I was reducing was in the rangelock bookkeeping.
So, for example, if multiple processes or multiple threads read or
write a file so
On 08/15/13 14:34, Ivan Voras wrote:
> On 15 August 2013 22:32, Colin Percival wrote:
>> No, I wasn't aware that it existed. Given that this change applies only to
>> parallel operations *on the same vnode* and blogbench seems to have traffic
>> randomly spread between many files, I doubt there w
On 15 August 2013 22:32, Colin Percival wrote:
> No, I wasn't aware that it existed. Given that this change applies only to
> parallel operations *on the same vnode* and blogbench seems to have traffic
> randomly spread between many files, I doubt there would be any difference.
Maybe it could h
On 08/15/13 13:29, Ivan Voras wrote:
> On 15 August 2013 22:19, Colin Percival wrote:
>> For workloads with R parallel reads and W parallel writes, this improves
>> the time spent from O((R+W)^2) to O(W*(R+W)); i.e., heavy parallel-read
>> workloads become significantly more scalable.
>>
>>
On 15 August 2013 22:19, Colin Percival wrote:
> For workloads with R parallel reads and W parallel writes, this improves
> the time spent from O((R+W)^2) to O(W*(R+W)); i.e., heavy parallel-read
> workloads become significantly more scalable.
>
> No statistically significant change in bu