On Mon, 26 Feb 2018, Yang Shi wrote:
Yup, see https://lwn.net/Articles/387720.Rather than killable, we have patches that introduce down_read_unfair()You mean you have such functionality used by google internally?
variants for the files you've modified (cmdline and environ) as well as
others (maps, numa_maps, smaps).
Right, it's solving two separate things which I think may be able to beWhen another thread is holding down_read() and there are queuedIt sounds the __unfair variant make the caller have chance to jump the gun to
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.
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?
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.
We make certain inferences on the readablility of procfs files for otherIngo would know more about whether a variant like that in upstream LinuxYes, I'm although it still looks overkilling to me for reading /proc.
would be acceptable.
Would you be interested in unfair variants instead of only addressing
killable?
threads to determine how much its mm's mmap_sem is contended.