lkml.org 
[lkml]   [2016]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC 0/12] introduce down_write_killable for rw_semaphore

* Michal Hocko <mhocko@kernel.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)

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

\
 
 \ /
  Last update: 2016-03-09 15:01    [W:0.072 / U:0.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site