* Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > [...] this is a follow up work for oom_reaper [1]. As the async OOM killing > > depends on oom_sem for read we would really appreciate if a holder for write > > stood in the way. This patchset is changing many of down_write calls to be > > killable to help those cases when the writer is blocked and waiting for > > readers to release the lock and so help __oom_reap_task to process the oom > > victim. > > > > there seems to be a misunderstanding: if a writer is blocked waiting for > > readers then no new readers are allowed - the writer will get its turn the > > moment all existing readers drop the lock. > > Readers might be blocked e.g. on the memory allocation which cannot proceed due > to OOM. Such a reader might be operating on a remote mm. Doing complex allocations with the mm locked looks fragile no matter what: we should add debugging code that warns if allocations are done with a remote mm locked. (it should be trivial) In fact people were thining about turning the mm semaphore into a rwlock - with that no blocking call should be possible with the lock held. So I maintain: > > So there's no livelock scenario - it's "only" about latencies. With a qualification: s/only/mostly ;-) > Latency is certainly one aspect of it as well because the sooner the mmap_sem > gets released for other readers to sooner the oom_reaper can tear down the > victims address space and release the memory and free up some memory so that we > do not have to wait for the victim to exit. > > > And once we realize that it's about latencies (assuming I'm right!), not about > > correctness per se, I'm wondering whether it would be a good idea to introduce > > down_write_interruptible(), instead of down_write_killable(). > > I am not against interruptible variant as well but I suspect that some paths are > not expected to return EINTR. I haven't checked them for this but killable is > sufficient for the problem I am trying to solve. That problem is real while > latencies do not seem to be that eminent. If they don't expect EINTR then they sure don't expect SIGKILL either! There's a (very) low number of system calls that are not interruptible, but the vast majority is. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
