Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp933423pxk; Fri, 25 Sep 2020 01:30:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxDPMrEwUY+RXrmL54/+E6VN/dyvZXGqESmn2g2N51Ej7R3YkCZd9syWleJNJ1DCr5eeogu X-Received: by 2002:a17:906:ae45:: with SMTP id lf5mr1522987ejb.339.1601022612464; Fri, 25 Sep 2020 01:30:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601022612; cv=none; d=google.com; s=arc-20160816; b=ahkj98KV3UsUHjOJsNuxc9sGCSgMINK4mkUU6iXUqB0/ix+VRDpKSGE3XTK4BKUKMf dYwjhnQLiAEI+BX+ZlbuVe949uFCzV3jM9i/ERdsDqXs9cQnGSYd+ZzqFyIpB76Lz8xe KDlIb+PXwCrRbLcZ5wmhSl+TGg+MibEgVL2q8tJkwKWMaCqMrouk3Ce2h8XnF4PhMT/X Ae7H9633LHyYxjvn65Hj9HeMuOjCMR5igcXaA087Lhw1W1fOSni+QBRpl37jFkUkAutI lobPlwRAIwWXOFOf9yxY+40xABRrShSHuuZEViIHlQwQU5lUrdassL8+872PZXwCs/mR TFNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=B26/iC+1mNbAVpwoje/bCXQml3NwgBVwZs92eAZmgtk=; b=FHNtLu0TOAdB1ikRrM27TNj7SrqVZ4WiRrN3yNgzISbDhGRKj9o6T0Khr4RT5xy8NM D/+f/hfVjGnuz60HrB3wzhuxuxRJj2lhhHq5XAkTDqxBRD8v3Q7QLtWXv4zP2GYfBI2+ NipIX3oCCvVtA2aKmICpIVzFIaxKRkGUruWeUvhZPqiq6/v1paq1cOQ2hXr+TLMPYRN4 W+p3C9lASPmunNhDnVZ+ewYooFTBsBzaZ5m0WyNVZvnlt+AoS22ub0l6dyA8g8YPDROt 8uJkfnG/PuwdS8Za9sBqX8gP0NKrGqoGoPWRzS1g0pK7ErYQYLeDTbJ8XQ3mvYmj282p dcEA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=merlin.20170209 header.b=PRR15rGJ; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s19si1725620eja.288.2020.09.25.01.29.49; Fri, 25 Sep 2020 01:30:12 -0700 (PDT) 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=@infradead.org header.s=merlin.20170209 header.b=PRR15rGJ; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727489AbgIYI0d (ORCPT + 99 others); Fri, 25 Sep 2020 04:26:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54186 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727044AbgIYI0c (ORCPT ); Fri, 25 Sep 2020 04:26:32 -0400 Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:8b0:10b:1231::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 473FCC0613CE; Fri, 25 Sep 2020 01:26:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=B26/iC+1mNbAVpwoje/bCXQml3NwgBVwZs92eAZmgtk=; b=PRR15rGJbRe4N3EQkHV+s2uXWX kPkr/QZht+Vz4q4dSYjAvMygE1DTeJcdgscWkQD7taAnDNUgfwG8k+x8zUS0rJ3/yZ9K8nrHSwEQq /SnQ6f8x++W54UMgfgyYI+wyOyi8WZNZv6qvs7mSASGKfmGfB6JgAFOknB+q7hBVrlE5opl2OnlCh a2LEfy2rUT17HgyAv9U+1V0Y4zTmhcFUOuB7SW/c479ytBV7Pun7QJffBUR1Kqlde2tWDgC5W2fOB tNo/TY4MZNZEt/jYydweut7xZVHnQeUdAQwdpzxgFjK6algKnRBPIPvylW3U/nEbYxviVl8fJgz0Y FVgsi/+Q==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1kLj3c-0003P0-Bs; Fri, 25 Sep 2020 08:26:20 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 4FCDA301A27; Fri, 25 Sep 2020 10:26:18 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 38B1A200D4BD1; Fri, 25 Sep 2020 10:26:18 +0200 (CEST) Date: Fri, 25 Sep 2020 10:26:18 +0200 From: Peter Zijlstra To: "Paul E. McKenney" Cc: Uladzislau Rezki , Mel Gorman , Michal Hocko , LKML , RCU , linux-mm@kvack.org, Andrew Morton , Vlastimil Babka , Thomas Gleixner , "Theodore Y . Ts'o" , Joel Fernandes , Sebastian Andrzej Siewior , Oleksiy Avramchenko , Mel Gorman Subject: Re: [RFC-PATCH 2/4] mm: Add __rcu_alloc_page_lockless() func. Message-ID: <20200925082618.GT2628@hirez.programming.kicks-ass.net> References: <20200921160318.GO12990@dhcp22.suse.cz> <20200921194819.GA24236@pc636> <20200922075002.GU12990@dhcp22.suse.cz> <20200922131257.GA29241@pc636> <20200923103706.GJ3179@techsingularity.net> <20200923154105.GO29330@paulmck-ThinkPad-P72> <20200923232251.GK3179@techsingularity.net> <20200924081614.GA14819@pc636> <20200924111907.GE2628@hirez.programming.kicks-ass.net> <20200924153834.GW29330@paulmck-ThinkPad-P72> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200924153834.GW29330@paulmck-ThinkPad-P72> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 24, 2020 at 08:38:34AM -0700, Paul E. McKenney wrote: > On Thu, Sep 24, 2020 at 01:19:07PM +0200, Peter Zijlstra wrote: > > On Thu, Sep 24, 2020 at 10:16:14AM +0200, Uladzislau Rezki wrote: > > > The key point is "enough". We need pages to make a) fast progress b) support > > > single argument of kvfree_rcu(one_arg). Not vice versa. That "enough" depends > > > on scheduler latency and vague pre-allocated number of pages, it might > > > be not enough what would require to refill it more and more or we can overshoot > > > that would lead to memory overhead. So we have here timing issues and > > > not accurate model. IMHO. > > > > I'm firmly opposed to the single argument kvfree_rcu() idea, that's > > requiring memory to free memory. > > Not quite. > > First, there is a fallback when memory allocation fails. Second, > in heavy-use situations, there is only one allocation per about > 500 kvfree_rcu() calls on 64-bit systems. Third, there are other > long-standing situations that require allocating memory in order to > free memory. Some of which are quite broken. And yes, I'm aware of all that, I'm the one that started swap-over-NFS, which requires network traffic to free memory, which is one insane step further. But the way to make that 'work' is carefully account and pre-allocate (or size the reserve) the required memory to make progress and to strictly limit concurrency to ensure you stay in your bounds. > So I agree that it is a good general rule of thumb to avoid allocating > on free paths, but there are exceptions. This is one of them. The very first thing you need to do is proof your memory usage is bounded, and then calculate your bound. The problem is that with RCU you can't limit concurrency. call_rcu() can't block, you can't wait for a grace period to end when you've ran out of your reserve. That is, you don't have a bound, so no reserve what so ever is going to help. You must have that callback_head fallback.