Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp979571pxb; Tue, 3 Nov 2020 18:49:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJwTGKtMXlyXbj/8sXnRFt6YyAMDbHhoN3PhZRj+r22Rkuo1B9sJ4IRJa2pyUfMScO9SICbp X-Received: by 2002:aa7:c948:: with SMTP id h8mr23843466edt.171.1604458153336; Tue, 03 Nov 2020 18:49:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604458153; cv=none; d=google.com; s=arc-20160816; b=FI/4SV2vv60on4uJY8Q8I/hAmO1mzHFhF0ykS7BaKvF/CLscM2ef/YS5RkIjRvQbCx sFh2I1sdBbUjNsBj4vhKH/28YHnagnNUa+JWAC5v6ebW4zfo+6Qi5DC3ok6WMZ0hJKdU azM2P4YUiZYRQm/+rhePSV+MI8+xOo1B+y97r98GGYX0ld9NsrCwoEksM/3mfWfV0F7C /WopUxdy3XWCLtkenkom8okf27eLDdhPtvGt1DbgVuq93UJBB+sALc4au5dhzaOFKXUN ynIfCgHq9QQ55gEjWp2K7PdRURFEhqIDayf/4lOojRZLcaEcRuUBNjc7SBAHxHGrHMnV Kd5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:organization :from:references:cc:to:subject:dkim-signature; bh=qnM3HUtIGwLfRlGLpYStqhjKzTQKX4TDNkJJOmXeLBg=; b=R6F27UNv4eSXHBwA566FNDUIp69xgXVgT40LPHlJHJxsM7Gm9L8eqj+uKFGsTSyMaH z+gS2qoyWbNyTxaUb3Mn+saH30TPnSlgSroOv4p4XqkR+P0SlIXPpkrggTbM2UlFmNpQ il/obXNsiNNOlhQGXQch5XPfsnQX1KgZVEgfOpTFOyUAumrKmbyLriPhR74hkYhoK6/H UzqKjXUzZ4BGeH5UmGRWrV2S7jv3dLQ9OVUF842pxYIIq9H7qna/XBL89ZOudqsPe2Ta GRZtVjiTSMc+xn1r19QEslSXGOK+BTp0KBF0JjP2cuYzoS2rZagu8Vi071u5ROfXjN7V 5lWw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=XqFrMAZV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id pk19si552729ejb.413.2020.11.03.18.48.49; Tue, 03 Nov 2020 18:49:13 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=XqFrMAZV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730665AbgKDCqh (ORCPT + 99 others); Tue, 3 Nov 2020 21:46:37 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:23649 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729745AbgKDCqg (ORCPT ); Tue, 3 Nov 2020 21:46:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1604457995; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qnM3HUtIGwLfRlGLpYStqhjKzTQKX4TDNkJJOmXeLBg=; b=XqFrMAZVmBSsODYvyygvYgPtYlkshyLz/u89OiPSDj5XbfFWQPUDhkIfpeJNPyVv66igqk pEzqdmR96f8rLDJzfpiZXgpsb09lzCUSpN3LV+u0VV41VqwO8+e1zKUOZssjsA045S3F0R JUaU6/DTUQMfFwHMMe/RwtmyQwL9kWA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-503-6xb81yOaNTW1rAbN2NnHSw-1; Tue, 03 Nov 2020 21:46:31 -0500 X-MC-Unique: 6xb81yOaNTW1rAbN2NnHSw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6E9D3107465A; Wed, 4 Nov 2020 02:46:28 +0000 (UTC) Received: from llong.remote.csb (ovpn-119-112.rdu2.redhat.com [10.10.119.112]) by smtp.corp.redhat.com (Postfix) with ESMTP id 82B4219C4F; Wed, 4 Nov 2020 02:46:26 +0000 (UTC) Subject: Re: [LKP] Re: [mm/memcg] bd0b230fe1: will-it-scale.per_process_ops -22.7% regression To: Xing Zhengjun , Michal Hocko , Rong Chen Cc: Linus Torvalds , Andrew Morton , Shakeel Butt , Chris Down , Johannes Weiner , Roman Gushchin , Tejun Heo , Vladimir Davydov , Yafang Shao , LKML , lkp@lists.01.org, lkp@intel.com, zhengjun.xing@intel.com References: <20201102091543.GM31092@shao2-debian> <20201102092754.GD22613@dhcp22.suse.cz> <82d73ebb-a31e-4766-35b8-82afa85aa047@intel.com> <20201102100247.GF22613@dhcp22.suse.cz> From: Waiman Long Organization: Red Hat Message-ID: Date: Tue, 3 Nov 2020 21:46:26 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/3/20 8:20 PM, Xing Zhengjun wrote: > > > On 11/2/2020 6:02 PM, Michal Hocko wrote: >> On Mon 02-11-20 17:53:14, Rong Chen wrote: >>> >>> >>> On 11/2/20 5:27 PM, Michal Hocko wrote: >>>> On Mon 02-11-20 17:15:43, kernel test robot wrote: >>>>> Greeting, >>>>> >>>>> FYI, we noticed a -22.7% regression of >>>>> will-it-scale.per_process_ops due to commit: >>>>> >>>>> >>>>> commit: bd0b230fe14554bfffbae54e19038716f96f5a41 ("mm/memcg: unify >>>>> swap and memsw page counters") >>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git >>>>> master >>>> I really fail to see how this can be anything else than a data >>>> structure >>>> layout change. There is one counter less. >>>> >>>> btw. are cgroups configured at all? What would be the configuration? >>> >>> Hi Michal, >>> >>> We used the default configure of cgroups, not sure what >>> configuration you >>> want, >>> could you give me more details? and here is the cgroup info of >>> will-it-scale >>> process: >>> >>> $ cat /proc/3042/cgroup >>> 12:hugetlb:/ >>> 11:memory:/system.slice/lkp-bootstrap.service >> >> OK, this means that memory controler is enabled and in use. Btw. do you >> get the original performance if you add one phony page_counter after the >> union? >> > I add one phony page_counter after the union and re-test, the > regression reduced to -1.2%. It looks like the regression caused by > the data structure layout change. So it looks like the regression is caused by false cacheline sharing of two or more hot items in mem_cgroup. As the size of the page_counter is 112 bytes, eliminating one counter will shift down the cacheline boundary by 16 bytes. We probably need to use perf to find out what those hot items are for this particular benchmark. Cheers, Longman