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.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,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 14BB2C43466 for ; Mon, 21 Sep 2020 16:03:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7A9772151B for ; Mon, 21 Sep 2020 16:03:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b="kXHdjAeJ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7A9772151B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id F230C6B0127; Mon, 21 Sep 2020 12:03:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ED41F6B0128; Mon, 21 Sep 2020 12:03:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D9BFE6B0129; Mon, 21 Sep 2020 12:03:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0163.hostedemail.com [216.40.44.163]) by kanga.kvack.org (Postfix) with ESMTP id BFE976B0127 for ; Mon, 21 Sep 2020 12:03:21 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 6D7B4362C for ; Mon, 21 Sep 2020 16:03:21 +0000 (UTC) X-FDA: 77287538202.10.worm33_13038bb27146 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin10.hostedemail.com (Postfix) with ESMTP id 1F3D816A4B0 for ; Mon, 21 Sep 2020 16:03:21 +0000 (UTC) X-HE-Tag: worm33_13038bb27146 X-Filterd-Recvd-Size: 4674 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf48.hostedemail.com (Postfix) with ESMTP for ; Mon, 21 Sep 2020 16:03:20 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1600704199; 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: in-reply-to:in-reply-to:references:references; bh=1ltLMHo8mqz5GoZ6lqc2SgPYV21CASPBptZBtk9bwlA=; b=kXHdjAeJr+2wQw+dd9MPLRVpAvmxx1000cDa1jOidrybBPZk8C607Eky/QZN5L9KCG3wKM Y/gAXeT+x/WWRgo759rM/gW4UefRoAlgvBhCYbMwnTDgb68nkpyPS1YZsQvo4GnDmBGB3d W9/++PwMx1z6USStYNsSooKYSdCQYLU= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 4B363AFE1; Mon, 21 Sep 2020 16:03:55 +0000 (UTC) Date: Mon, 21 Sep 2020 18:03:18 +0200 From: Michal Hocko To: "Paul E. McKenney" Cc: "Uladzislau Rezki (Sony)" , LKML , RCU , linux-mm@kvack.org, Andrew Morton , Peter Zijlstra , Vlastimil Babka , Thomas Gleixner , "Theodore Y . Ts'o" , Joel Fernandes , Sebastian Andrzej Siewior , Oleksiy Avramchenko Subject: Re: [RFC-PATCH 2/4] mm: Add __rcu_alloc_page_lockless() func. Message-ID: <20200921160318.GO12990@dhcp22.suse.cz> References: <20200918194817.48921-1-urezki@gmail.com> <20200918194817.48921-3-urezki@gmail.com> <20200921074716.GC12990@dhcp22.suse.cz> <20200921154558.GD29330@paulmck-ThinkPad-P72> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200921154558.GD29330@paulmck-ThinkPad-P72> 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 Mon 21-09-20 08:45:58, Paul E. McKenney wrote: > On Mon, Sep 21, 2020 at 09:47:16AM +0200, Michal Hocko wrote: > > On Fri 18-09-20 21:48:15, Uladzislau Rezki (Sony) wrote: > > [...] > > > Proposal > > > ======== > > > Introduce a lock-free function that obtain a page from the per-cpu-lists > > > on current CPU. It returns NULL rather than acquiring any non-raw spinlock. > > > > I was not happy about this solution when we have discussed this > > last time and I have to say I am still not happy. This is exposing > > an internal allocator optimization and allows a hard to estimate > > consumption of pcp free pages. IIUC this run on pcp cache can be > > controled directly from userspace (close(open) loop IIRC) which makes it > > even bigger no-no. > > Yes, I do well remember that you are unhappy with this approach. > Unfortunately, thus far, there is no solution that makes all developers > happy. You might be glad to hear that we are also looking into other > solutions, each of which makes some other developers unhappy. So we > are at least not picking on you alone. :-/ No worries I do not feel like a whipping boy here. But do expect me to argue against the approach. I would also appreciate it if there was some more information on other attempts, why they have failed. E.g. why pre-allocation is not an option that works well enough in most reasonable workloads. I would also appreciate some more thoughts why we need to optimize for heavy abusers of RCU (like close(open) extremes). > > I strongly agree with Thomas http://lkml.kernel.org/r/87tux4kefm.fsf@nanos.tec.linutronix.de > > that this optimization is not aiming at reasonable workloads. Really, go > > with pre-allocated buffer and fallback to whatever slow path you have > > already. Exposing more internals of the allocator is not going to do any > > good for long term maintainability. > > I suggest that you carefully re-read the thread following that email. I clearly remember Thomas not being particularly happy that you optimize for a corner case. I do not remember there being a consensus that this is the right approach. There was some consensus that this is better than a gfp flag. Still quite bad though if you ask me. > Given a choice between making users unhappy and making developers > unhappy, I will side with the users each and every time. Well, let me rephrase. It is not only about me (as a developer) being unhappy but also all the side effects this would have for users when performance of their favorite workload declines for no apparent reason just because pcp caches are depleted by an unrelated process. -- Michal Hocko SUSE Labs