Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2223680imm; Tue, 10 Jul 2018 15:51:15 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcGi0bP+e8THPUz1vKExq39aiuzJiOMH0YiRwapiUFXw3W98I/XBan7Mm0xtNYTxbwCa597 X-Received: by 2002:a65:5141:: with SMTP id g1-v6mr24097921pgq.418.1531263075155; Tue, 10 Jul 2018 15:51:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531263075; cv=none; d=google.com; s=arc-20160816; b=aRKIx1cnulMrjzEUWxH77JkClN2ZTJeiU5rYynC5Ts/HdtSCEx+/ZeKAb9wc2MOvwx ab+bueB2bZTf2sBPdxUyTiJ6FcjmDEC0rv5nous44ytbAuFPaHgitxTw7UlSoojHMEi8 vZSEjL2GWnK2EXWIDmg/H6WAc0HvIhPSgtZ9lO+I8mR4EWkMkqZiBNFpf9ZPuCiZKFWz Ww4/qZuZbBcWmn8gbrQw8PDODZlkIkXosaPLwalKtSfeoBGgni8BTdPOFGqZdXz3cc11 ziZYbD2CDkybVlK+WN4iKrm+gFB8+F0k13E8XHrDNK8mwS4JWBR/6lhBbHk6WbzF/Ysg n+Vg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=yuXR3m7SX4tm0inN8nSSthuLXHSyt+saiZH6ZTjtZ9E=; b=u1Vz3T1D47dejA4WOBXNGVbc550tYE5IZy7LH1UGTs3Nz+j2Cp2GmJB6pep4plwXnH cvkj76llFGaoCHhxF2SXy3raOK1M1ZOJOkga3ThleLE8Ow5gic1Zrii3iDdobESruXnj JzFAcg0I6xUXJ54fbTaJZueOyrmbdlVI0uIN9V/+ka+nCeUnBSNBXxoUu6jelOHt8HPd ccjB5icNcv47EunVCWjV4pelO5kiH+9OgPFi2NAiLHAbbahe/gkQEFnMvZpEFvmx5N9B NW77Waay2fDahNgCb/MwDBshALw0rUOQ7aDqsZ9EaD+KFPVlA2rQlAV5Xc3nzk2lSg27 IjLQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2018-07-02 header.b=44R+uOQU; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d22-v6si6389497pfj.311.2018.07.10.15.50.59; Tue, 10 Jul 2018 15:51:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2018-07-02 header.b=44R+uOQU; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732298AbeGJWvI (ORCPT + 99 others); Tue, 10 Jul 2018 18:51:08 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:54708 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732263AbeGJWvI (ORCPT ); Tue, 10 Jul 2018 18:51:08 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w6AMnMNn054759; Tue, 10 Jul 2018 22:49:22 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=corp-2018-07-02; bh=yuXR3m7SX4tm0inN8nSSthuLXHSyt+saiZH6ZTjtZ9E=; b=44R+uOQUFei2z6ykQJ8j7nm6Tc/I0yeHs79gkBAxtDojX2GQBPmySFXg3KGKrC8tVooo fjQPllrglg2bvdBf6Oh5hMoMSzKCWUM29U2DtCf5wZrGoaEDwKM3OnB0w2D6BokEoeNg gmv8pzucYLLAaztXAxTxvkgWjZ8qn2ebWmzR9XRAIjEtuFswOHx4CackMhQJSnM03OAg Nc2xfMS5bU5WnCEmFwd+EHwwu74DcDwBUGc7ZUa13rRKpTRycR/ch3AS09X+vxhl8Ksd 43YoyVkwNMuaHsMQ8zfIRmcGBjdGhGYYkr8dMg7xHGmHQVAFdVQDCnlo1shjf5l84KoY TQ== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2130.oracle.com with ESMTP id 2k2p763x2c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 10 Jul 2018 22:49:22 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w6AMnLUM001183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 10 Jul 2018 22:49:21 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w6AMnJwm020445; Tue, 10 Jul 2018 22:49:19 GMT Received: from ca-dmjordan1.us.oracle.com (/10.211.9.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 10 Jul 2018 15:49:19 -0700 Date: Tue, 10 Jul 2018 15:49:23 -0700 From: Daniel Jordan To: "Huang, Ying" Cc: Daniel Jordan , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" , Andrea Arcangeli , Michal Hocko , Johannes Weiner , Shaohua Li , Hugh Dickins , Minchan Kim , Rik van Riel , Dave Hansen , Naoya Horiguchi , Zi Yan Subject: Re: [PATCH -mm -v4 14/21] mm, cgroup, THP, swap: Support to move swap account for PMD swap mapping Message-ID: <20180710224923.lm5n7d2jot6pggw2@ca-dmjordan1.us.oracle.com> References: <20180622035151.6676-1-ying.huang@intel.com> <20180622035151.6676-15-ying.huang@intel.com> <20180709172037.254zyuadep2hj5po@ca-dmjordan1.us.oracle.com> <87tvp7h6mx.fsf@yhuang-dev.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87tvp7h6mx.fsf@yhuang-dev.intel.com> User-Agent: NeoMutt/20180323-268-5a959c X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8950 signatures=668706 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807100243 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 10, 2018 at 03:49:58PM +0800, Huang, Ying wrote: > Daniel Jordan writes: > > > On Fri, Jun 22, 2018 at 11:51:44AM +0800, Huang, Ying wrote: > >> Because there is no way to prevent a huge swap cluster from being > >> split except when it has SWAP_HAS_CACHE flag set. > > > > What about making get_mctgt_type_thp take the cluster lock? That function > > would be the first lock_cluster user outside of swapfile.c, but it would > > serialize with split_swap_cluster. > > > >> It is possible for > >> the huge swap cluster to be split and the charge for the swap slots > >> inside to be changed, after we check the PMD swap mapping and the huge > >> swap cluster before we commit the charge moving. But the race window > >> is so small, that we will just ignore the race. > > > > Moving the charges is a slow path, so can't we just be correct here and not > > leak? > > Check the code and thought about this again, found the race may not > exist. Because the PMD is locked when get_mctgt_type_thp() is called > until charge is completed for the PMD. So the charge of the huge swap > cluster cannot be changed at the same time even if the huge swap cluster > is split by other processes. That's true, the PMD lock does prevent the swap charge from going stale between the time mem_cgroup_move_charge_pte_range identifies a huge swap entry in get_mctgt_type_thp and the time it moves the charge in mem_cgroup_move_account, at least for some events like swapping in pages. > Right? I'm not sure the PMD lock covers everything, but after looking a while longer at this, the charge moving seems to be a best-effort feature in other respects, so the accounting doesn't need to be completely accurate.