On Thu 16-04-15 10:04:17, Andy Lutomirski wrote: > On Thu, Apr 16, 2015 at 8:01 AM, David Herrmann <dh.herrm...@gmail.com> wrote: > > Hi > > > > On Thu, Apr 16, 2015 at 4:34 PM, Andy Lutomirski <l...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
