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;
Date:   Wed, 18 Nov 2020 11:34:46 -0800
From:   Roman Gushchin <guro@fb.com>
To:     Vlastimil Babka <vbabka@suse.cz>
CC:     Bharata B Rao <bharata@linux.ibm.com>,
        <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
        <cl@linux.com>, <rientjes@google.com>, <iamjoonsoo.kim@lge.com>,
        <akpm@linux-foundation.org>, <shakeelb@google.com>,
        <hannes@cmpxchg.org>, <aneesh.kumar@linux.ibm.com>
Subject: Re: [RFC PATCH v0] mm/slub: Let number of online CPUs determine the
 slub page order
Message-ID: <20201118193446.GC186396@carbon.dhcp.thefacebook.com>
References: <20201118082759.1413056-1-bharata@linux.ibm.com>
 <9e1a2e2b-1b3c-9587-9b74-8ed8300fcb98@suse.cz>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9e1a2e2b-1b3c-9587-9b74-8ed8300fcb98@suse.cz>
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from carbon.dhcp.thefacebook.com (2620:10d:c090:400::5:508d) by MWHPR22CA0011.namprd22.prod.outlook.com (2603:10b6:300:ef::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Wed, 18 Nov 2020 19:34:50 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: f9c8bdb5-1f3a-4d62-534b-08d88bf904e6
X-MS-TrafficTypeDiagnostic: BYAPR15MB2277:
X-Microsoft-Antispam-PRVS: <BYAPR15MB22772E78E3270CEDE8AEC490BEE10@BYAPR15MB2277.namprd15.prod.outlook.com>
X-FB-Source: Internal
X-MS-Oob-TLC-OOBClassifiers: OLM:8882;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: PWbeVQLSQXQzTCzJCENonMfnA34C1vMjnJljlFVMHJc4Zhsk6Y0xaIVHNl945B825DhocgRcho+UsEuF1orSwrMjYZchBOJeF3OQ/I3LMPigQpmvI7F8eO0BS0KIBB1A0/V6rU/unQaM0tI/Dn1UL3F3Vrk0hpnWe6sXqm6hzRwrnBSHf+SQxOb6N78dwWB8PIIh2m7V11/zQab7HEHP5ASWOEEvkmFSz6tanmxt/5lMLRkWANIeOWFUMkt4t+VJtwu3U+K9Bsf2bc54KJVg9zRqOdNQraVMdn5zid3lppKxTL48h0hPEwZ5Y3MALDsVrs5trUKZ6mcBnCWmB+wADA==
X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BYAPR15MB4136.namprd15.prod.outlook.com;PTR:;CAT:NONE;SFS:(136003)(366004)(39860400002)(396003)(376002)(346002)(478600001)(66946007)(2906002)(33656002)(8936002)(52116002)(8676002)(53546011)(6666004)(316002)(186003)(16526019)(6506007)(83380400001)(66476007)(7696005)(86362001)(4326008)(5660300002)(66556008)(55016002)(6916009)(7416002)(9686003)(1076003);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData: pVCkQTwcY6jYfcv1jcK9CT77WT6W+hOqxb08PoOJXVyagzGVBsD2N12ypGDl4+f4gF/91uJzOriPf54nhCp11ZlvxqtLKVFCF4JJsfQ2b+A21jNH+CWL2N5jDtEJq6KnTsk84IEP8Tjp4w3ULG00trc7t6Aalc6lNbUZEmVVd1GDgD9FzY27XIWaGYauYSuAnqlti8h98YAgxd8xDOl16ya7xv+yH6GDF85CEHJHvuWHOUPo7A+/0/tlEX7kzYJu3TjTG/5HJK+WjWWwnAzpvMMmq68NPYZvAe5BK5/3cm5q/h5NE04A0pYeh1cFmhwMHk8Nb+w9MrLzavR0aSX8ubDG2EAUttnCmmUu7+68B4xriUor3cFpJ4HS2zf/ofBtgX/562BxAwEviTzYTesvMB+nr/qp7BUG/+8Hz2RqVA4IzlRstjkuo0U6/4gI34MK5vsehbAWNH4Pdy8RyE/8hgpooCWRwTisSOXbx5euQrD1TIx3HSuKbkQt83GIgMbWgQ32Qo8NSuAew8+3ckklrUFOi8SfRLR7bAdVdmrdbJZOFigig8UvHnQ8t6b9/58qmHPre37QQJlvHUQkzl/pz0+l5IWPs3lyf9kfhcTIyndn/EPjXwslblyEyeTZ6YJ1mbkxGl0CleGaBUO+ypaLG1ra+ZCWN2qA9YHMBx+caqw=
X-MS-Exchange-CrossTenant-Network-Message-Id: f9c8bdb5-1f3a-4d62-534b-08d88bf904e6
X-MS-Exchange-CrossTenant-AuthSource: BYAPR15MB4136.namprd15.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Nov 2020 19:34:52.0954
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: gzDLtOcuMQnZjTz0eYLNqjmQDZ76ZsrOMiDZ0U7Nco/lxz4/j3k0flG1i2APw07Q
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2277
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312,18.0.737
 definitions=2020-11-18_06:2020-11-17,2020-11-18 signatures=0
X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 clxscore=1015
 malwarescore=0 priorityscore=1501 suspectscore=1 spamscore=0
 impostorscore=0 adultscore=0 phishscore=0 lowpriorityscore=0
 mlxlogscore=996 mlxscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.12.0-2009150000 definitions=main-2011180135
X-FB-Internal: deliver
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Nov 18, 2020 at 12:25:38PM +0100, Vlastimil Babka wrote:
> On 11/18/20 9:27 AM, Bharata B Rao wrote:
> > The page order of the slab that gets chosen for a given slab
> > cache depends on the number of objects that can be fit in the
> > slab while meeting other requirements. We start with a value
> > of minimum objects based on nr_cpu_ids that is driven by
> > possible number of CPUs and hence could be higher than the
> > actual number of CPUs present in the system. This leads to
> > calculate_order() chosing a page order that is on the higher
> > side leading to increased slab memory consumption on systems
> > that have bigger page sizes.
> > 
> > Hence rely on the number of online CPUs when determining the
> > mininum objects, thereby increasing the chances of chosing
> > a lower conservative page order for the slab.
> > 
> > Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
> 
> Acked-by: Vlastimil Babka <vbabka@suse.cz>
> 
> Ideally, we would react to hotplug events and update existing caches
> accordingly. But for that, recalculation of order for existing caches would
> have to be made safe, while not affecting hot paths. We have removed the
> sysfs interface with 32a6f409b693 ("mm, slub: remove runtime allocation
> order changes") as it didn't seem easy and worth the trouble.
> 
> In case somebody wants to start with a large order right from the boot
> because they know they will hotplug lots of cpus later, they can use
> slub_min_objects= boot param to override this heuristic. So in case this
> change regresses somebody's performance, there's a way around it and thus
> the risk is low IMHO.

I agree. For the absolute majority of users there will be no difference.
And there is a good workaround for the rest.

Acked-by: Roman Gushchin <guro@fb.com>