From: Michal Hocko <mhocko@kernel.org> To: Ingo Molnar <mingo@kernel.org> Cc: LKML <linux-kernel@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>, Thomas Gleixner <tglx@linutronix.de>, "H. Peter Anvin" <hpa@zytor.com>, "David S. Miller" <davem@davemloft.net>, Tony Luck <tony.luck@intel.com>, Andrew Morton <akpm@linux-foundation.org>, Chris Zankel <chris@zankel.net>, Max Filippov <jcmvbkbc@gmail.com>, x86@kernel.org, linux-alpha@vger.kernel.org, linux-ia64@vger.kernel.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, linux-arch@vger.kernel.org, Linus Torvalds <torvalds@linux-foundation.org>, Peter Zijlstra <a.p.zijlstra@chello.nl> Subject: Re: [RFC 0/12] introduce down_write_killable for rw_semaphore Date: Wed, 09 Mar 2016 12:56:41 +0000 [thread overview] Message-ID: <20160309125641.GH27018@dhcp22.suse.cz> (raw) In-Reply-To: <20160309121850.GA14915@gmail.com> On Wed 09-03-16 13:18:50, Ingo Molnar wrote: > > * Michal Hocko <mhocko@kernel.org> wrote: > > > Hi, > > > > the following patchset implements a killable variant of write lock for > > rw_semaphore. My usecase is to turn as many mmap_sem write users to use a > > killable variant which will be helpful for the oom_reaper [1] to asynchronously > > tear down the oom victim address space which requires mmap_sem for read. This > > will reduce a likelihood of OOM livelocks caused by oom victim being stuck on a > > lock or other resource which prevents it to reach its exit path and release the > > memory. [...] > > So I'm a tiny bit concerned about this arguments. > > AFAICS killability here just makes existing system calls more interruptible - > right? see below > In that sense that's not really a livelock scenario: it just takes shorter > time for resources to be released. > > If a livelock is possible (where resources are never released) then I'd like to > see a specific example of such a livelock. > > You have the other patch-set: > > [PATCH 0/18] change mmap_sem taken for write killable > > that makes use of down_write_killable(), and there you argue: > > [...] 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. > So there's no livelock scenario - it's "only" about latencies. 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. down_write_interruptible will be trivial to do on top. -- Michal Hocko SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org> To: Ingo Molnar <mingo@kernel.org> Cc: LKML <linux-kernel@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>, Thomas Gleixner <tglx@linutronix.de>, "H. Peter Anvin" <hpa@zytor.com>, "David S. Miller" <davem@davemloft.net>, Tony Luck <tony.luck@intel.com>, Andrew Morton <akpm@linux-foundation.org>, Chris Zankel <chris@zankel.net>, Max Filippov <jcmvbkbc@gmail.com>, x86@kernel.org, linux-alpha@vger.kernel.org, linux-ia64@vger.kernel.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, linux-arch@vger.kernel.org, Linus Torvalds <torvalds@linux-foundation.org>, Peter Zijlstra <a.p.zijlstra@chello.nl> Subject: Re: [RFC 0/12] introduce down_write_killable for rw_semaphore Date: Wed, 9 Mar 2016 13:56:41 +0100 [thread overview] Message-ID: <20160309125641.GH27018@dhcp22.suse.cz> (raw) In-Reply-To: <20160309121850.GA14915@gmail.com> On Wed 09-03-16 13:18:50, Ingo Molnar wrote: > > * Michal Hocko <mhocko@kernel.org> wrote: > > > Hi, > > > > the following patchset implements a killable variant of write lock for > > rw_semaphore. My usecase is to turn as many mmap_sem write users to use a > > killable variant which will be helpful for the oom_reaper [1] to asynchronously > > tear down the oom victim address space which requires mmap_sem for read. This > > will reduce a likelihood of OOM livelocks caused by oom victim being stuck on a > > lock or other resource which prevents it to reach its exit path and release the > > memory. [...] > > So I'm a tiny bit concerned about this arguments. > > AFAICS killability here just makes existing system calls more interruptible - > right? see below > In that sense that's not really a livelock scenario: it just takes shorter > time for resources to be released. > > If a livelock is possible (where resources are never released) then I'd like to > see a specific example of such a livelock. > > You have the other patch-set: > > [PATCH 0/18] change mmap_sem taken for write killable > > that makes use of down_write_killable(), and there you argue: > > [...] 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. > So there's no livelock scenario - it's "only" about latencies. 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. down_write_interruptible will be trivial to do on top. -- Michal Hocko SUSE Labs
next prev parent reply other threads:[~2016-03-09 12:56 UTC|newest] Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-02-02 20:19 [RFC 0/12] introduce down_write_killable for rw_semaphore Michal Hocko 2016-02-02 20:19 ` Michal Hocko 2016-02-02 20:19 ` [RFC 01/12] locking, rwsem: get rid of __down_write_nested Michal Hocko 2016-02-02 20:19 ` Michal Hocko 2016-02-02 20:19 ` [RFC 02/12] locking, rwsem: drop explicit memory barriers Michal Hocko 2016-02-02 20:19 ` Michal Hocko 2016-02-02 20:19 ` [RFC 03/12] locking, rwsem: introduce basis for down_write_killable Michal Hocko 2016-02-02 20:19 ` Michal Hocko 2016-02-02 20:19 ` [RFC 04/12] alpha, rwsem: provide __down_write_killable Michal Hocko 2016-02-02 20:19 ` Michal Hocko 2016-02-02 20:19 ` [RFC 05/12] ia64, " Michal Hocko 2016-02-02 20:19 ` Michal Hocko 2016-02-02 20:19 ` [RFC 06/12] s390, " Michal Hocko 2016-02-02 20:19 ` Michal Hocko 2016-02-02 20:19 ` [RFC 07/12] sh, " Michal Hocko 2016-02-02 20:19 ` Michal Hocko 2016-02-03 11:19 ` Sergei Shtylyov 2016-02-03 11:19 ` Sergei Shtylyov 2016-02-03 12:11 ` Michal Hocko 2016-02-03 12:11 ` Michal Hocko 2016-02-02 20:19 ` [RFC 08/12] sparc, " Michal Hocko 2016-02-02 20:19 ` Michal Hocko 2016-02-02 20:19 ` [RFC 09/12] xtensa, " Michal Hocko 2016-02-02 20:19 ` Michal Hocko 2016-02-02 20:19 ` [RFC 10/12] x86, rwsem: simplify __down_write Michal Hocko 2016-02-02 20:19 ` Michal Hocko 2016-02-03 8:10 ` Ingo Molnar 2016-02-03 8:10 ` Ingo Molnar 2016-02-03 12:10 ` Michal Hocko 2016-02-03 12:10 ` Michal Hocko 2016-06-03 16:13 ` Peter Zijlstra 2016-06-03 16:13 ` Peter Zijlstra 2016-06-03 22:34 ` Peter Zijlstra 2016-06-03 22:34 ` Peter Zijlstra 2016-06-09 14:40 ` David Howells 2016-06-09 14:40 ` David Howells 2016-06-09 17:36 ` Peter Zijlstra 2016-06-09 17:36 ` Peter Zijlstra 2016-06-10 16:39 ` Paul E. McKenney 2016-06-10 16:39 ` Paul E. McKenney 2016-02-02 20:19 ` [RFC 11/12] x86, rwsem: provide __down_write_killable Michal Hocko 2016-02-02 20:19 ` Michal Hocko 2016-02-17 16:41 ` [RFC 11/12 v1] " Michal Hocko 2016-02-17 16:41 ` Michal Hocko 2016-02-17 16:41 ` Michal Hocko 2016-02-17 16:41 ` Michal Hocko 2016-02-02 20:19 ` [RFC 12/12] locking, rwsem: provide down_write_killable Michal Hocko 2016-02-02 20:19 ` Michal Hocko 2016-02-19 12:15 ` [RFC 0/12] introduce down_write_killable for rw_semaphore Michal Hocko 2016-02-19 12:15 ` Michal Hocko 2016-03-09 12:18 ` Ingo Molnar 2016-03-09 12:18 ` Ingo Molnar 2016-03-09 12:56 ` Michal Hocko [this message] 2016-03-09 12:56 ` Michal Hocko 2016-03-09 13:17 ` Ingo Molnar 2016-03-09 13:17 ` Ingo Molnar 2016-03-09 13:28 ` Michal Hocko 2016-03-09 13:28 ` Michal Hocko 2016-03-09 13:43 ` Ingo Molnar 2016-03-09 13:43 ` Ingo Molnar 2016-03-09 14:41 ` Michal Hocko 2016-03-09 14:41 ` Michal Hocko 2016-03-10 10:24 ` Ingo Molnar 2016-03-10 10:24 ` Ingo Molnar
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20160309125641.GH27018@dhcp22.suse.cz \ --to=mhocko@kernel.org \ --cc=a.p.zijlstra@chello.nl \ --cc=akpm@linux-foundation.org \ --cc=chris@zankel.net \ --cc=davem@davemloft.net \ --cc=hpa@zytor.com \ --cc=jcmvbkbc@gmail.com \ --cc=linux-alpha@vger.kernel.org \ --cc=linux-arch@vger.kernel.org \ --cc=linux-ia64@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-s390@vger.kernel.org \ --cc=linux-sh@vger.kernel.org \ --cc=linux-xtensa@linux-xtensa.org \ --cc=mingo@kernel.org \ --cc=mingo@redhat.com \ --cc=peterz@infradead.org \ --cc=sparclinux@vger.kernel.org \ --cc=tglx@linutronix.de \ --cc=tony.luck@intel.com \ --cc=torvalds@linux-foundation.org \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.