lkml.org 
[lkml]   [2019]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: pagecache locking
From
Date
On 06/07/2019 02:31, Dave Chinner wrote:

>
> As long as the IO ranges to the same file *don't overlap*, it should
> be perfectly safe to take separate range locks (in read or write
> mode) on either side of the mmap_sem as non-overlapping range locks
> can be nested and will not self-deadlock.
>
> The "recursive lock problem" still arises with DIO and page faults
> inside gup, but it only occurs when the user buffer range overlaps
> the DIO range to the same file. IOWs, the application is trying to
> do something that has an undefined result and is likely to result in
> data corruption. So, in that case I plan to have the gup page faults
> fail and the DIO return -EDEADLOCK to userspace....
>

This sounds very cool. I now understand. I hope you put all the tools
for this in generic places so it will be easier to salvage.

One thing I will be very curious to see is how you teach lockdep
about the "range locks can be nested" thing. I know its possible,
other places do it, but its something I never understood.

> Cheers,
> Dave.

[ Ha one more question if you have time:

In one of the mails, and you also mentioned it before, you said about
the rw_read_lock not being able to scale well on mammoth machines
over 10ns of cores (maybe you said over 20).
I wonder why that happens. Is it because of the atomic operations,
or something in the lock algorithm. In my theoretical understanding,
as long as there are no write-lock-grabbers, why would the readers
interfere with each other?
]

Thanks
Boaz

\
 
 \ /
  Last update: 2019-07-07 17:06    [W:0.181 / U:0.644 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site