Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754280AbbDQSzI (ORCPT ); Fri, 17 Apr 2015 14:55:08 -0400 Received: from mail-la0-f48.google.com ([209.85.215.48]:34387 "EHLO mail-la0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753977AbbDQSzF (ORCPT ); Fri, 17 Apr 2015 14:55:05 -0400 MIME-Version: 1.0 In-Reply-To: <20150417091947.GA13951@dhcp22.suse.cz> References: <20150415085641.GH16381@kroah.com> <20150415120618.4d8d90ff@lxorguk.ukuu.org.uk> <552E8B11.4010803@redhat.com> <20150417091947.GA13951@dhcp22.suse.cz> From: Andy Lutomirski Date: Fri, 17 Apr 2015 11:54:42 -0700 Message-ID: Subject: Re: [GIT PULL] kdbus for 4.1-rc1 To: Michal Hocko Cc: David Herrmann , Tom Gundersen , Havoc Pennington , Rik van Riel , One Thousand Gnomes , Greg Kroah-Hartman , Jiri Kosina , Linus Torvalds , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , "linux-kernel@vger.kernel.org" , Daniel Mack , Djalal Harouni Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2260 Lines: 49 On Fri, Apr 17, 2015 at 2:19 AM, Michal Hocko wrote: > On Thu 16-04-15 10:04:17, Andy Lutomirski wrote: >> On Thu, Apr 16, 2015 at 8:01 AM, David Herrmann wrote: >> > Hi >> > >> > On Thu, Apr 16, 2015 at 4:34 PM, Andy Lutomirski 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/