lkml.org 
[lkml]   [2015]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] kdbus for 4.1-rc1
On Thu 16-04-15 10:04:17, Andy Lutomirski wrote:
> On Thu, Apr 16, 2015 at 8:01 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
> > Hi
> >
> > On Thu, Apr 16, 2015 at 4:34 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> >> Whose memcg does the pool use?
> >
> > The pool-owner's (i.e., the receiver's).
> >
> >> If it's the receiver's, and if the
> >> receiver can configure a memcg, then it seems that even a single
> >> receiver could probably cause the sender to block for an unlimited
> >> amount of time.
> >
> > How? Which of those calls can block? I don't see how that can happen.
>
> I admit I don't fully understand memcg, but vfs_iter_write is
> presumably going to need to get write access to the target pool page,
> and that, in turn, will need that page to exist in memory and to be
> writable, which may need to page it in and/or allocate a page. If
> that uses the receiver's memcg (as it should), then the receiver can
> make it block. Even if it doesn't use the receiver's memcg, it can
> trigger direct reclaim, I think.

Yes, memcg direct reclaim might trigger but we are no longer waiting for
the OOM victim from non page fault paths so the time is bounded. It
still might a quite some time, though, depending on the amount of work
done in the direct reclaim.
--
Michal Hocko
SUSE Labs


\
 
 \ /
  Last update: 2015-04-17 11:41    [W:0.251 / U:1.836 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site