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=-3.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 7CC5EC433DF for ; Mon, 12 Oct 2020 13:30:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C7479204EA for ; Mon, 12 Oct 2020 13:30:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg-org.20150623.gappssmtp.com header.i=@cmpxchg-org.20150623.gappssmtp.com header.b="vnTw9dJf" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C7479204EA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CCD44940007; Mon, 12 Oct 2020 09:30:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C7D0A900002; Mon, 12 Oct 2020 09:30:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B44E8940007; Mon, 12 Oct 2020 09:30:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0151.hostedemail.com [216.40.44.151]) by kanga.kvack.org (Postfix) with ESMTP id 86393900002 for ; Mon, 12 Oct 2020 09:30:36 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 16FDF181AC9CC for ; Mon, 12 Oct 2020 13:30:36 +0000 (UTC) X-FDA: 77363358072.12.ship89_570fe78271fa Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin12.hostedemail.com (Postfix) with ESMTP id E47ED18010A49 for ; Mon, 12 Oct 2020 13:30:35 +0000 (UTC) X-HE-Tag: ship89_570fe78271fa X-Filterd-Recvd-Size: 5214 Received: from mail-qk1-f196.google.com (mail-qk1-f196.google.com [209.85.222.196]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Mon, 12 Oct 2020 13:30:35 +0000 (UTC) Received: by mail-qk1-f196.google.com with SMTP id a23so17644613qkg.13 for ; Mon, 12 Oct 2020 06:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=pnPTIBXyXY3lw9klvumgMEMiErvTNBjNm3i9R50FiO8=; b=vnTw9dJflaMIXNnNWw2vi/vOaGk2yCJ69WDQkdY4C16AMLkPTm9WzibqnJrH3CiqcT mJCxscrz0aU5tFQt3oG+TShN2wD1khwShvSZmM7v3nm7O0dWqniUMmRiLZDDQYjBBccN EQJUREQlsKPdgYnTyxfYxpHc0vHmAkbUNFICmbFU9qwruHcZYxq++kzYmfP+Jt3WKH/u s9pLL3UOpMht2Ts8ZdKF5KM7CdNLZlGJtrvSuo0yDSxa4ZuiVm8uVJZWBNWu3bOhsbRd aG5OPdQLY7OH+3bI0F0c0UQ5AwXOA6uNU9dy12iV8LG4GQPFUMJU45SjR9KBubkniWJy zj0A== 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=pnPTIBXyXY3lw9klvumgMEMiErvTNBjNm3i9R50FiO8=; b=nPltYTuPAV2f5MQEdP772oQBFMtawI3CvhGNB8tCUdOBREI/lB20oFgUdWKbzzJWIC GffOSIj8TvhBV1n4LTYncWJA6y5Sd5wO2bBWE9L8yBUftNXEzEvmGDJ6LZrr0DJmt/zL WamaJiEL7AuXcDlxCtoNd6dWO35Q4Jfh27glUvrVdkFwPlypPYKtmNZ+iq/ar8qXeu1I bHAdSHTTDMgv6i5Ruzarnf4MmcHIW/eLvM85zN5k7KyTVdIQ3c3YRkpsvKfRQpTQGp5t u/ChATgmgpDLqHl6UPfLsuacIYhKqc0De4Ggq5LWb6OaGnF02jIX1jVnqSigLE+e/klW D8SQ== X-Gm-Message-State: AOAM530xUUhzFzvqdUNqeH4RfnKocvycVy0nggHBBwbii1XZjt6kM3z2 PUP/wXSs+2ILF90unl9qV8KWIg== X-Google-Smtp-Source: ABdhPJxcAtD+DVNW0Lo9o9FmYxCJnyvNR7wF/YxZxRmvawTGsigNtgwmZAfyvj+gqt87sq8Idn2hFA== X-Received: by 2002:a05:620a:16cb:: with SMTP id a11mr10048726qkn.474.1602509434380; Mon, 12 Oct 2020 06:30:34 -0700 (PDT) Received: from localhost (pool-96-232-200-60.nycmny.fios.verizon.net. [96.232.200.60]) by smtp.gmail.com with ESMTPSA id x91sm7657123qte.69.2020.10.12.06.30.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Oct 2020 06:30:33 -0700 (PDT) Date: Mon, 12 Oct 2020 09:28:59 -0400 From: Johannes Weiner To: Ralph Campbell Cc: Andrew Morton , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Michal Hocko , Vladimir Davydov , =?iso-8859-1?B?Suly9G1l?= Glisse , Balbir Singh , Ira Weiny , stable@vger.kernel.org Subject: Re: [PATCH] mm/memcg: fix device private memcg accounting Message-ID: <20201012132859.GD163830@cmpxchg.org> References: <20201009215952.2726-1-rcampbell@nvidia.com> <20201009155055.f87de51ea04d4ea879e3981a@linux-foundation.org> 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 Fri, Oct 09, 2020 at 05:00:37PM -0700, Ralph Campbell wrote: > > On 10/9/20 3:50 PM, Andrew Morton wrote: > > On Fri, 9 Oct 2020 14:59:52 -0700 Ralph Campbell wrote: > > > > > The code in mc_handle_swap_pte() checks for non_swap_entry() and returns > > > NULL before checking is_device_private_entry() so device private pages > > > are never handled. > > > Fix this by checking for non_swap_entry() after handling device private > > > swap PTEs. The fix looks good to me. Acked-by: Johannes Weiner > > But this makes me suspect the answer is "there aren't any that we know > > of". Are you sure a cc:stable is warranted? > > > > I assume the memory cgroup accounting would be off somehow when moving > a process to another memory cgroup. > Currently, the device private page is charged like a normal anonymous page > when allocated and is uncharged when the page is freed so I think that path is OK. > Maybe someone who knows more about memory cgroup accounting can comment? As for whether to CC stable, I'm leaning toward no: - When moving tasks, we'd leave their device pages behind in the old cgroup. This isn't great, but it doesn't cause counter imbalances or corruption or anything - we also skip locked pages, we used to skip pages mapped by more than one pte, the user can select whether to move pages along tasks at all, and if so, whether only anon or file. - Charge moving itself is a bit of a questionable feature, and users have been moving away from it. Leaving tasks in a cgroup and changing the configuration is a heck of a lot cheaper than moving potentially gigabytes of pages to another configuration domain. - According to the Fixes tag, this isn't a regression, either. Since their inception, we have never migrated device pages.