On Mon, 26 Feb 2018, Yang Shi wrote: > > Rather than killable, we have patches that introduce down_read_unfair() > > variants for the files you've modified (cmdline and environ) as well as > > others (maps, numa_maps, smaps). > > You mean you have such functionality used by google internally? >
Yup, see https://lwn.net/Articles/387720. > > When another thread is holding down_read() and there are queued > > down_write()'s, down_read_unfair() allows for grabbing the rwsem without > > queueing for it. Additionally, when another thread is holding > > down_write(), down_read_unfair() allows for queueing in front of other > > threads trying to grab it for write as well. > > It sounds the __unfair variant make the caller have chance to jump the gun to > grab the semaphore before other waiters, right? But when a process holds the > semaphore, i.e. mmap_sem, for a long time, it still has to sleep in > uninterruptible state, right? > Right, it's solving two separate things which I think may be able to be merged together. Killable is solving an issue where the rwsem is blocking for a long period of time in uninterruptible sleep, and unfair is solving an issue where reading the procfs files gets stalled for a long period of time. We haven't run into an issue (yet) where killable would have solved it; we just have the unfair variants to grab the rwsem asap and then, if killable, gracefully return. > > Ingo would know more about whether a variant like that in upstream Linux > > would be acceptable. > > > > Would you be interested in unfair variants instead of only addressing > > killable? > > Yes, I'm although it still looks overkilling to me for reading /proc. > We make certain inferences on the readablility of procfs files for other threads to determine how much its mm's mmap_sem is contended.
