Date:	Wed, 9 Mar 2016 14:28:55 +0100
From:	Michal Hocko <mhocko@...nel.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	"David S. Miller" <davem@...emloft.net>,
	Tony Luck <tony.luck@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Chris Zankel <chris@...kel.net>,
	Max Filippov <jcmvbkbc@...il.com>, x86@...nel.org,
	linux-alpha@...r.kernel.org, linux-ia64@...r.kernel.org,
	linux-s390@...r.kernel.org, linux-sh@...r.kernel.org,
	sparclinux@...r.kernel.org, linux-xtensa@...ux-xtensa.org,
	linux-arch@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [RFC 0/12] introduce down_write_killable for rw_semaphore

On Wed 09-03-16 14:17:10, Ingo Molnar wrote:
> 
> * Michal Hocko <mhocko@...nel.org> 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)

No matter how fragile is that it is not something non-existent. Just
have a look at use_mm for example. We definitely do not want to warn
about those, right?

> 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!

Why? Each syscall already is killable as the task might be killed by the
OOM killer.

> There's a (very) low number of system calls that are not interruptible, but the 
> vast majority is.

That might be true. I just fail to see how this is related to the
particular problem I am trying to solve. As I've said those callsites
which cause problems with latencies can be later converted to
interruptible waiting trivially.

-- 
Michal Hocko
SUSE Labs

Powered by blists - more mailing lists