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=-1.0 required=3.0 tests=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 9AA55C83000 for ; Tue, 28 Apr 2020 12:42:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 65ED8206D7 for ; Tue, 28 Apr 2020 12:42:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 65ED8206D7 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 EA9FD8E0005; Tue, 28 Apr 2020 08:42:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E5B628E0001; Tue, 28 Apr 2020 08:42:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D49598E0005; Tue, 28 Apr 2020 08:42:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0129.hostedemail.com [216.40.44.129]) by kanga.kvack.org (Postfix) with ESMTP id B94038E0001 for ; Tue, 28 Apr 2020 08:42:25 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 7249E180AD806 for ; Tue, 28 Apr 2020 12:42:25 +0000 (UTC) X-FDA: 76757227050.30.queen19_6c6e7bd152a3f X-HE-Tag: queen19_6c6e7bd152a3f X-Filterd-Recvd-Size: 4223 Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Tue, 28 Apr 2020 12:42:25 +0000 (UTC) Received: by mail-wm1-f65.google.com with SMTP id x4so2592660wmj.1 for ; Tue, 28 Apr 2020 05:42:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Ijc16TZoAovOIZNKOLnCZ8Mp7weYQTKsEdNWQm6piC0=; b=CvGQT5Meq1yZLUc9ZefaBEhw45pZEyeN0YMYrzXVtVYrrBhCzmOQSuHSXZpH7DDS4B HgWXDGwqoNMhkU6oZJVxWlCqdz3qcIwdRcnj7B2VQypq0FqGT/84Mo/WZ31UymCubdNV LC7eLL/zF0T5yBfR4yHXbXIset+PHgA85eRJ8l2WhhptrOHpufn1MNP4MLkfckVXA4vl zgObyTxx6/dMvF6YxDvbvvKYiGDDJE7smTRu7kj2we0hPTzJT3JU0NSWIJlcdusakGyW PfRWbLZ8dR7j8yMvW4V6eN7t0K57RBC3/CeEw6DVfAUWgVKeGvs0SCXGMsJ+9fewkZmd iT0Q== X-Gm-Message-State: AGi0PuaUwoCCGnek8flhk/EpmcKgl9+urAec/FMZWvFtTQnbb5JBsbdJ qFZMeCUOzOLeyEBjiK5IqNo= X-Google-Smtp-Source: APiQypL11IuI7tk1RPWwXGJOxL69trw1N0cmbzq0Mx446TO3AEd/iBXk+lw6RP1mSdP+QjMjv+Ks9Q== X-Received: by 2002:a1c:9852:: with SMTP id a79mr4336632wme.27.1588077743946; Tue, 28 Apr 2020 05:42:23 -0700 (PDT) Received: from localhost (ip-37-188-130-62.eurotel.cz. [37.188.130.62]) by smtp.gmail.com with ESMTPSA id m1sm24653783wro.64.2020.04.28.05.42.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Apr 2020 05:42:23 -0700 (PDT) Date: Tue, 28 Apr 2020 14:42:22 +0200 From: Michal Hocko To: Yafang Shao Cc: Johannes Weiner , Andrew Morton , Roman Gushchin , Chris Down , Linux MM Subject: Re: [PATCH 0/3] mm: improve proportional memcg protection Message-ID: <20200428124222.GR28637@dhcp22.suse.cz> References: <20200425152418.28388-1-laoar.shao@gmail.com> <20200427170540.GB29022@cmpxchg.org> <20200428080525.GL28637@dhcp22.suse.cz> <20200428104300.GN28637@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Tue 28-04-20 20:25:49, Yafang Shao wrote: > On Tue, Apr 28, 2020 at 6:43 PM Michal Hocko wrote: [...] > > [...] > > > > So it would be really more helpful to not insist on unrelated > > > > implementation details and focus on two things 1) split up the effective > > > > values calculation from the predicate (cleanup without any functional > > > > changes) 2) make the calculation more robust against racing reclaimers. > > > > > > > > > > Another thing should be considered as well, 0) don't access > > > memroy.emin and elow in get_scan_count(). > > > > If you can achieve the gradual transition over protections by other > > means then I am really interested in more details. > > sc->protection I believe I have covered this one already. > I make my statement again - accessing the realy fragile emin & elow > in very deep reclaiming code is a totally horrible HACK, that is the > root of all evil. Both me and Johannes tried to explain that we simply have to calculate effective values for the whole reclaim tree. That has to be done somehow. Caching effective values is a tricky solution but I am not really aware of another without requiring to allocate storage for intermediate results. Maybe there is a way to make that storage really small to live on the stack or some other tricks. If you do not have any clever ideas how to achieve that then we have to live with the caching at the memcg level. And then we have to deal with 2) mentioned above. -- Michal Hocko SUSE Labs