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=-2.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 3AB0FC47257 for ; Mon, 4 May 2020 14:22:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F04BE20752 for ; Mon, 4 May 2020 14:21:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="jIHpH8tC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F04BE20752 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 90A768E001B; Mon, 4 May 2020 10:21:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 894478E0003; Mon, 4 May 2020 10:21:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 784678E001B; Mon, 4 May 2020 10:21:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0091.hostedemail.com [216.40.44.91]) by kanga.kvack.org (Postfix) with ESMTP id 5CA438E0003 for ; Mon, 4 May 2020 10:21:59 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 0C0E48248D51 for ; Mon, 4 May 2020 14:21:59 +0000 (UTC) X-FDA: 76779250758.18.shade88_1146684bf7947 X-HE-Tag: shade88_1146684bf7947 X-Filterd-Recvd-Size: 5356 Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Mon, 4 May 2020 14:21:58 +0000 (UTC) Received: by mail-lf1-f68.google.com with SMTP id w14so9925898lfk.3 for ; 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=tA2Yi7ll3RQSaWMgkXitZ7hXVlf3CzWqKo3THm1T+jGm6uwSmEzo6MtIDcho4g8SNE AdT5JxsCIg7qQh0rOVliNMDCn930ceDNY4AyUV9t3yAK8SL2y7s3r76oqn2yzwE0ruVu LFREm1dIB5irKn9t8UNavd7gsgKE1KW9eZsYKXsgW+rzFrgUmWVcFOFWiZebkWQ2uu1a F3BcBKwv2mJSGP3t/SZER8gZf2V8C6CBR+PBOrxNQ5uzvdTdzTPeo8RFyjmmgoqhAzFf RhgsKiDraDzyltAxhJoMbEu9QZvucE4QoFTnluU2z/tavjurE7sVvEKpETN9pCsg2/fU yXbw== X-Gm-Message-State: AGi0PuZfUvvvY4V2e7IyhezYi5wqe6eshTWrg/5YayIOfLQQgvWxsd2k t1J9i9bzChSbvsKy9FH2wOI= X-Google-Smtp-Source: APiQypILiwgc6kOVf1Dh9xb4iNYqSTwVc8ILuaP2SqMOrOHSXjRr2sAkPPlMPKjIkNV0biK7ivNAUA== 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) 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: > > > > > > 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