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 7FC9CC11D05 for ; Thu, 20 Feb 2020 15:56:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4243E24656 for ; Thu, 20 Feb 2020 15:56:54 +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="ESOkYp4w" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4243E24656 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 DA5846B0003; Thu, 20 Feb 2020 10:56:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D56BA6B0006; Thu, 20 Feb 2020 10:56:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C6D2E6B0007; Thu, 20 Feb 2020 10:56:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0248.hostedemail.com [216.40.44.248]) by kanga.kvack.org (Postfix) with ESMTP id B0F546B0003 for ; Thu, 20 Feb 2020 10:56:53 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 5956F181AEF1F for ; Thu, 20 Feb 2020 15:56:53 +0000 (UTC) X-FDA: 76510958706.15.way74_1eff61f2a6532 X-HE-Tag: way74_1eff61f2a6532 X-Filterd-Recvd-Size: 5095 Received: from mail-qk1-f196.google.com (mail-qk1-f196.google.com [209.85.222.196]) by imf29.hostedemail.com (Postfix) with ESMTP for ; Thu, 20 Feb 2020 15:56:52 +0000 (UTC) Received: by mail-qk1-f196.google.com with SMTP id o28so3986439qkj.9 for ; Thu, 20 Feb 2020 07:56:52 -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=WrIAIkuYfbohT4URY+WT9f9IMynxvVzhUx7hJqz7oAk=; b=ESOkYp4wOyqNJWtsVeoAd/ssWk0nvkvCqnwMaCaF3sumNcZ7bZUGH+0ucazaesndy0 yirD6ztauUJJvTh2k0qQOCMIuSy8y0I5Op0djhJN8tXc86SkhYb3GRAvPH0Xdg20PLhR tkP4CLoOD5zcFyv/N+6KLjwu32UptfltbOtBQhs2lFBq9bhdey1qQykNbSqzme1HWTvF YJKe9824y9fv3QDFnPj2iRvGn8faVc36cGixbcfn6JihAAnsRa6TRztLTkXfYeKmfck4 JQ0bQjj5RuwY3aPQVQLPJ5lDRI+ouoTLCgEgk4zeilfjXu6dAxWPxxTsm/zvTFmQrkVB y1rw== 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=WrIAIkuYfbohT4URY+WT9f9IMynxvVzhUx7hJqz7oAk=; b=qwwuqhBzBgjRvomDF1/wC6lVr09n3BVlXl9Yg1KVqYkGZ1/UMDwDVvDAiCpMDHNQ1A qtt7bsm7BdRi3qhCC2ZoKIWhJmOIxNXJwdLZWKqN7R/60rlPNYi02ZaA1KTDkSgicDRB JdJsZWpL6xeZXowwkMze34tpnbalscPnHJ4RxuRxbeTui8C5Gue5k5JTM2iyQpcCA7BQ L+IOAGmDxYut11hcpjL4K0Bq3DWFnXiedqxukdWLM32SDRtEVjxU2+oPvkVm5KGwObgA gK3io10pYoPjjaQwgEZJmCdowVNgl+ocdZGXVePntisz4Nd5eimP3cK8mBpdXwxzIRrY aXjA== X-Gm-Message-State: APjAAAUhN5myuZXPqW/WWByLfhjhllg3Z7Q3OjA7iG/C6lSPOv0FEb1r HW0nX60Tsjm9hRjTeb0pTS0= X-Google-Smtp-Source: APXvYqxl2VFYhPNB5rqU5j+Wp99qIWsjSoVAVV6XHVaiOidOGQt4AO4LYzBpRqNGmdzKRoW3+dg+/w== X-Received: by 2002:a05:620a:31b:: with SMTP id s27mr28175423qkm.105.1582214212209; Thu, 20 Feb 2020 07:56:52 -0800 (PST) Received: from localhost ([2620:10d:c091:500::5e31]) by smtp.gmail.com with ESMTPSA id x66sm57180qkb.101.2020.02.20.07.56.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Feb 2020 07:56:51 -0800 (PST) Date: Thu, 20 Feb 2020 10:56:51 -0500 From: Tejun Heo To: Daniel Jordan Cc: Johannes Weiner , Michal Hocko , Andrew Morton , Roman Gushchin , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, Peter Zijlstra Subject: Re: [PATCH] mm: memcontrol: asynchronous reclaim for memory.high Message-ID: <20200220155651.GG698990@mtj.thefacebook.com> References: <20200219181219.54356-1-hannes@cmpxchg.org> <20200219183731.GC11847@dhcp22.suse.cz> <20200219191618.GB54486@cmpxchg.org> <20200219195332.GE11847@dhcp22.suse.cz> <20200219214112.4kt573kyzbvmbvn3@ca-dmjordan1.us.oracle.com> <20200219220859.GF54486@cmpxchg.org> <20200220154524.dql3i5brnjjwecft@ca-dmjordan1.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200220154524.dql3i5brnjjwecft@ca-dmjordan1.us.oracle.com> 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: On Thu, Feb 20, 2020 at 10:45:24AM -0500, Daniel Jordan wrote: > Ok, consistency with io and memory is one advantage to doing it that way. > Creating kthreads in cgroups also seems viable so far, and it's unclear whether > either approach is significantly simpler or more maintainable than the other, > at least to me. The problem with separate kthread approach is that many of these work units are tiny, and cgroup membership might not be known or doesn't agree with the processing context from the beginning For example, the ownership of network packets can't be determined till processing has progressed quite a bit in shared contexts and each item too small to bounce around. The only viable way I can think of splitting aggregate overhead according to the number of packets (or some other trivially measureable quntity) processed. Anything sitting in reclaim layer is the same. Reclaim should be charged to the cgroup whose memory is reclaimed *but* shouldn't block other cgroups which are waiting for that memory. It has to happen in the context of the highest priority entity waiting for memory but the costs incurred must be charged to the memory owners. So, one way or the other, I think we'll need back charging and once back charging is needed for big ticket items like network and reclaim, it's kinda silly to use separate mechanisms for other stuff. > Is someone on your side working on remote charging right now? I was planning > to post an RFD comparing these soon and it would make sense to include them. It's been on the to do list but nobody is working on it yet. Thanks. -- tejun