Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp3663371ybz; Mon, 4 May 2020 07:25:02 -0700 (PDT) X-Google-Smtp-Source: APiQypIfFkkxatgAGoJNj82m7ACFDY2DBK17mIGe4OSNXKmcp5LLp3LWvfO38VVB19EhbenSksx8 X-Received: by 2002:a17:906:48c:: with SMTP id f12mr15564674eja.93.1588602302016; Mon, 04 May 2020 07:25:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588602302; cv=none; d=google.com; s=arc-20160816; b=aRb75cDC070a4EICSjQ3m2lHUmBBaqNNxGwI1gsLPKCRJJ4eS1yy6JXs1y/36J6Ebo vO1U8y8ecSIFQc/lUMzmsPWqy4gTUoy1a0W1MwltqrPaeH0HC18ACSAwXC/7x1cMxSdB YvR8twh/XLXf/gCIfr1tVECEypA9r2Ddtay/aK85TjGADze4ZUPH2H21FzpmKq928vYN QlVUbHCM84r4nQm8cG+JMr9JxoFPWMHd7GHd4+j/3cgGsvJSb+Bm4NVDqprd1W8CO7ru OXdlJO0lRhqDSZL3KUZR6qLmfRZPjXoQNQEriqMvbAxIYLq02K3Ff6Wt+JBee0/7NqOw g73A== 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:date:from:dkim-signature; bh=TjQIadq6DfkSuMtzgbVyqx7eozFCGzVHUTUogoGl7xY=; b=uKkEHIQLpc125XpVKhSeTZU3l73hgFpiEIb5pq21ZuCVwmzsjrJDAtqvqx90xHE+2U 1Wfy5G+jOVP2EDoi93l6Ia6NKMNTLwzDUGmq96Dp6iUxL1m8Alm3AiV4NQ3QmHCF6XwO mbd74uvDxkr7lVk0S8+sSCGlyvveAeirI+XR9q5UG1NLT+CVy2jLvMM02qpE+YnZWHlS PaVegn/sFzGKRpLssnugV5M/oWxXBO28JCCEu4U+FoUyCKaKeXo8zDfswFrcy1QRxJcn lm+fDX0Kbllnofqq32Njx0NeDnrl9WnHaYgjOXC1+omfI+l57nNfkC/fRSQbOTUol0+U PZzA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=jIHpH8tC; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ld23si6755968ejb.242.2020.05.04.07.24.38; Mon, 04 May 2020 07:25:01 -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=@gmail.com header.s=20161025 header.b=jIHpH8tC; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728993AbgEDOV7 (ORCPT + 99 others); Mon, 4 May 2020 10:21:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50982 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728168AbgEDOV7 (ORCPT ); Mon, 4 May 2020 10:21:59 -0400 Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BDA7AC061A0E; Mon, 4 May 2020 07:21:58 -0700 (PDT) Received: by mail-lf1-x142.google.com with SMTP id s9so4702521lfp.1; Mon, 04 May 2020 07:21:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=TjQIadq6DfkSuMtzgbVyqx7eozFCGzVHUTUogoGl7xY=; b=jIHpH8tCYXoUS/6yaeKsETWsdPAiDMK0RP02iwGzjzLK/nJ8eRqBiYJJ6etliXLip1 8PlROGndEGmJOkQb+GS9LVPB3FjI/MyuzkbiZRHX56/PrN7HKjF2MNK1lcG9iht/JBKj hLlEk94jUha/lV4BWoFcV0WMPSo7uT2Jd/gVUmwmSdtW5KGcs6BhIPFLRhAgiP5Pxv+v BDvR1GlfLHarnpA6VBkpl5OLGpVFPs5Q4OEZHGxcJNpQiO6jXq/ERSTvVesCLxKVONId VMWRwzA4I0+tRUnuEkWEW7ZJY7TQNm00e0rgLEzgjIKJvhmvUgcnnwT8X7qCQfIuQttN ZFaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=TjQIadq6DfkSuMtzgbVyqx7eozFCGzVHUTUogoGl7xY=; b=K2frAgdxWXGL0XWJSaUpWGKdrq255SBlQqOoLPOKmmBtA8ZoB/XLqPV7k63SPDlnof mQ7OXCQlh6ZetAQ//79DGSgWE7ov7H+Fw8gIV1R7+1M3lKjb3zNZnl/vLIIfDf2xdZqy +PTuYVRJr0f1gh9na0E2ogYR6ny7dEDupNqdDmyyaL9DI6oIEiY3/eh6B53rPs1WDk1c R9Te8g7jjMxQOlvkQrCFshFGPVu4cxPpD12zq6H78Gr7zUXI6yd5sHm91WtS2UBO0FZj +DjenE47ZW+FxvINZqn52jV++/kRyLkwrGnrHgWncsXVVKXW5x3d+V8XFrF3Kv8RUdqV su9A== X-Gm-Message-State: AGi0PuZZoDja/zqWVXue3J0o/xGCemk+Rnt9oarHN38WMhkrq7orlNJ+ XxFnbaCjWiEbt0cGi5HqUQVdCNcPxz8e5Q== X-Received: by 2002:a05:6512:31d6:: with SMTP id j22mr11613555lfe.83.1588602117162; Mon, 04 May 2020 07:21:57 -0700 (PDT) Received: from pc636 (h5ef52e31.seluork.dyn.perspektivbredband.net. [94.245.46.49]) by smtp.gmail.com with ESMTPSA id a2sm8363646ljj.53.2020.05.04.07.21.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 May 2020 07:21:55 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Mon, 4 May 2020 16:21:53 +0200 To: Joel Fernandes , "Paul E. McKenney" Cc: "Paul E. McKenney" , "Uladzislau Rezki (Sony)" , LKML , linux-mm@kvack.org, Andrew Morton , "Theodore Y . Ts'o" , Matthew Wilcox , RCU , Oleksiy Avramchenko Subject: Re: [PATCH 19/24] rcu/tree: Support reclaim for head-less object Message-ID: <20200504142153.GG17577@pc636> References: <20200428205903.61704-1-urezki@gmail.com> <20200428205903.61704-20-urezki@gmail.com> <20200501223909.GF7560@paulmck-ThinkPad-P72> <20200504001258.GD197097@google.com> <20200504002855.GF2869@paulmck-ThinkPad-P72> <20200504003237.GD212435@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200504003237.GD212435@google.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > > > > > If we are not doing single-pointer allocation, then that would also eliminate > > > entering the low-level page allocator for single-pointer allocations. > > > > > > Or did you mean entry into the allocator for the full-page allocations > > > related to the pointer array for PREEMPT_RT? Even if we skip entry into the > > > allocator for those, we will still have additional caching which further > > > reduces chances of getting a full page. In the event of such failure, we can > > > simply queue the rcu_head. > > > > > > Thoughts? > > > > I was just trying to guess why you kept the single-pointer allocation. > > It looks like I guessed wrong. ;-) > > > > If, as you say above, you make it go straight to synchronize_rcu() > > upon full-page allocation failure, that would be good! > > Paul, sounds good. Vlad, are you also Ok with that? > OK, let's drop it and keep it simple :) BTW, for PREEMPT_RT we still can do a page allocation for single argument of kvfree_rcu(). In case of double we just revert everything to the rcu_head if no cache. For single argument we can drop the lock before the entry to the page allocator. Because it follows might_sleep() anotation we avoid of having a situation when spinlock(rt mutex) is taken from any atomic context. Since the lock is dropped the current context can be interrupted by an IRQ which in its turn can also call kvfree_rcu() on current CPU. In that case it must be double argument(single is not allowed) kvfree_rcu() call. For PREEMPT_RT if no cache everything is reverted to rcu_head usage, i.e. the entry to page allocator is bypassed. It can be addressed as a separate patch and send out later on if we are on the same page. Paul, Joel what are your opinions? -- Vlad Rezki