Messages in this thread | | | From | Andy Lutomirski <> | Date | Fri, 17 Apr 2015 11:54:42 -0700 | Subject | Re: [GIT PULL] kdbus for 4.1-rc1 |
| |
On Fri, Apr 17, 2015 at 2:19 AM, Michal Hocko <mhocko@suse.cz> wrote: > 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.
Is that still true if OOM notifiers are involved? I've lost track of what changed there.
Any any event, I'm not entirely convinced that having a broadcast send cause, say, PID 1 to block until an unbounded number of pages in a potentially unbounded number of memcgs are reclaimed is a good idea.
In the kdbus model's favor, I think that allowing pages of data in the receive queue to be swapped out is potentially quite nice, but I'm less convinced about non-full pages in the receive queue. There's a resource management tradeoff here, and one nice thing about AF_UNIX is that sends are genuinely non-blocking.
--Andy
| |