From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B32D5C3B19F for ; Fri, 14 Feb 2020 15:41:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 79D422467D for ; Fri, 14 Feb 2020 15:41:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ZbT6gpBk" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 79D422467D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4D3CE6B0635; Fri, 14 Feb 2020 10:41:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4AA5F6B0637; Fri, 14 Feb 2020 10:41:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3BFC16B0638; Fri, 14 Feb 2020 10:41:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0128.hostedemail.com [216.40.44.128]) by kanga.kvack.org (Postfix) with ESMTP id 21D8A6B0635 for ; Fri, 14 Feb 2020 10:41:02 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id A7D7D181AEF1A for ; Fri, 14 Feb 2020 15:41:01 +0000 (UTC) X-FDA: 76489145922.28.knot67_7d50923087103 X-HE-Tag: knot67_7d50923087103 X-Filterd-Recvd-Size: 5937 Received: from mail-qv1-f66.google.com (mail-qv1-f66.google.com [209.85.219.66]) by imf09.hostedemail.com (Postfix) with ESMTP for ; Fri, 14 Feb 2020 15:41:01 +0000 (UTC) Received: by mail-qv1-f66.google.com with SMTP id l14so4441622qvu.12 for ; Fri, 14 Feb 2020 07:41:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=PUP4np+G4VE7PuRhOk6undkvvxru+QNxEyvlFdHRy8M=; b=ZbT6gpBkKjiYBwLqeSqmGvHliwzu3GiTDD1TN6F1csmbHvQf5zew22ys7x8sByZCFB q48R1dqd6gb7760yQUKvX4ZNOKbkvtwgVXPFolXQrQXFKuoaSdlGKyGE+fp8z//c61Hd 9aFr16nzHuax9MVICJO+adiLztmf99s8R7h4dW7aDkTdvIDlLGhEAskwkWWFDaMuKHh+ EBqbHa95IoXx+rusv2pI09ldunnEOGJq3Ra9uXfWr3ii4cIPUeeLkQmcWl2DMBT4FrBk hTj1LXm+1GQmksx8ne1jW4r0o3tNzCKAJvVd/3eOw9vI5C/TQEWBf3N/WArbWsU/bI6K f3iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=PUP4np+G4VE7PuRhOk6undkvvxru+QNxEyvlFdHRy8M=; b=r9DC72QfRPcumMGnewA/FceC0e0+DZcldVLqYc+gYZ9t/iyUIN+cJRPMt+gTJoAESu iQ4DYuZ3JPa7WyN1faQpaEj/cIY8KnBVlSPZaDvK+Xu1NStw7Nb7gLcHxJRUuk/r43mt M7GHgE4sWSe0EHqBJT2NnKKnyK1oSaLCT8DOf401H65/RjfGv4GTILxgqJCJGqcfmJQA S6OclYW1cJQ2OBqHI8Y2Jh1qBpt5FVwffpDUnaaUO3olMDKJn75chClwunvBU7rldWVg Dif0EULAybsnu+sEOL7jbaXaw1j6OUtihFf7O50NHoLsQ5P73a01oCvIHZx/XpMVcavR +NnQ== X-Gm-Message-State: APjAAAUcDcoodYUYrZDvMVHId1iM1vUlkiGRyc4vqGQpfgaBh7j4V6LX AhdIEeGEkcuTJOl7O7uqPCc= X-Google-Smtp-Source: APXvYqxdW4fylNswjll7xxYrCS6rXZrMDa0xELAOaKYQie0LHhRSG3Il+FkHWaO6Oesbu4IpntutBQ== X-Received: by 2002:a0c:e408:: with SMTP id o8mr2707981qvl.236.1581694860207; Fri, 14 Feb 2020 07:41:00 -0800 (PST) Received: from localhost ([71.172.127.161]) by smtp.gmail.com with ESMTPSA id s22sm3440963qke.19.2020.02.14.07.40.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Feb 2020 07:40:59 -0800 (PST) Date: Fri, 14 Feb 2020 10:40:57 -0500 From: Tejun Heo To: Michal Hocko Cc: Johannes Weiner , Andrew Morton , Roman Gushchin , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH v2 3/3] mm: memcontrol: recursive memory.low protection Message-ID: <20200214154057.GM88887@mtj.thefacebook.com> References: <20200212170826.GC180867@cmpxchg.org> <20200213074049.GA31689@dhcp22.suse.cz> <20200213135348.GF88887@mtj.thefacebook.com> <20200213154731.GE31689@dhcp22.suse.cz> <20200213155249.GI88887@mtj.thefacebook.com> <20200213163636.GH31689@dhcp22.suse.cz> <20200213165711.GJ88887@mtj.thefacebook.com> <20200214071537.GL31689@dhcp22.suse.cz> <20200214135728.GK88887@mtj.thefacebook.com> <20200214151318.GC31689@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200214151318.GC31689@dhcp22.suse.cz> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hello, On Fri, Feb 14, 2020 at 04:13:18PM +0100, Michal Hocko wrote: > On Fri 14-02-20 08:57:28, Tejun Heo wrote: > > But that doesn't work for other controllers at all. I'm having a > > difficult time imagining how making this one control mechanism work > > that way makes sense. Memory protection has to be configured together > > with IO protection to be actually effective. > > Please be more specific. If the protected workload is mostly in-memory, > I do not really see how IO controller is relevant. See the example of > the DB setup I've mentioned elsewhere. Most applications, even the ones which don't use explicit IOs much, don't have set memory footprint which is uniformly accessed and there needs to be some level of reclaim activity for the working set to be established and maintained. Without IO control, memory protection isn't enough in protecting the workload. Even if we narrow down the discussion to something like memcache which has fixed memory footprint with almost uniform access pattern, real world applications don't exist in vacuum - they compete on CPU, have to do logging, pulls in metric ton of libraries which implicitly accesses stuff and so on. If somebody else is pummeling the filesystem and there's no IO isolation set up, it'll stall noticeably every once in a while. > > As for cgroup hierarchy being unrelated to how controllers behave, it > > frankly reminds me of cgroup1 memcg flat hierarchy thing I'm not sure > > how that would actually work in terms of resource isolation. Also, I'm > > not sure how systemd forces such configurations and I'd think systemd > > folks would be happy to fix them if there are such problems. Is the > > point you're trying to make "because of systemd, we have to contort > > how memory controller behaves"? > > No, I am just saying and as explained in reply to Johannes, there are > practical cases where the cgroup hierarchy reflects organizational > structure as well. Oh I see. If cgroup hierarchy isn't set up for resource control, resource control not working well seems par for the course. I mean, no other controllers would work anyway, so I'm having a hard time to see what the point is. What we ultimately want is cgroup actually being useful for its primary purpose of resource control while supporting other organizational use cases and while the established usages aren't there yet I haven't seen anything fundamentally blocking that. Thanks. -- tejun