Received: by 10.223.185.116 with SMTP id b49csp1122541wrg; Wed, 14 Feb 2018 12:00:55 -0800 (PST) X-Google-Smtp-Source: AH8x226cHtmTZrnnLL4Ev/1K5aTNsDsqs8+JU9XWFfFxpCwrnSfEeVnjJHiEJuT6Sv2kqVwCYnuF X-Received: by 10.101.85.143 with SMTP id j15mr117924pgs.387.1518638455656; Wed, 14 Feb 2018 12:00:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518638455; cv=none; d=google.com; s=arc-20160816; b=tDDbE5VBCeYc+BB8dYEV0HGCMjSBX6grANso4vPP+aFXjhPgEjM60HrwYGc7PqsOR0 0qossP+mKucXmxe/iSGJ/S8ikpABFx9ZcIzQ4fs9mHS17tLkFltrGlYQXpbiRr8Eexuj IT0RdAfsOaZB09TeF48X8fBvo+05FXhVIHYaXlk4TQgzG/mw7VrufmxdNJ+i1fTE9rDZ LJTljQgcUcoS17mfuXwP0fi2+6qtziBbji0SsAQimEtyTAkoefia4BJUqRgjLs/S1tp+ nKKuewxWC/YYUR6xkoZFqPWWcP4NAY43HlGErRHa1L84/Snus+ao0vnie+Vbr7NisyZ7 2qrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dmarc-filter :arc-authentication-results; bh=DXWe6JRzkzizTE+4+G82YS18B7eBqbDC5WldYlV9L84=; b=TKgY3HnLiIdOuAnA3KRkoCEKGFI+K0geFTAiWNiZagClSKY9/Q30FpoUxHDAXymLgX +ZDyqkcoDoqGLsoxEP3BwJ/6+QVNkhrXSSO1MuHJdfPlhVYmXuEzjXHHuqDQAfYcj1J6 F0xXqYM6BPcTFu5SuNtm6IQwtgOMlg1V0R9Tuof7DI/uZu8A07ICms0K7T48c5rHv8ba WljutekBdlUaniualF+z/veilu/o0Ik/xlSh3h1EMKaV3t4wHfPzs2xGPpIfTdbGHws9 cBo0rOLpjs6UOyIAw3NAwmWpicWX2IwaRzWxCbOws3JVpD5sX74lpH+YeLhn/AC2LV0a xOzA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o10si1713049pgf.102.2018.02.14.12.00.41; Wed, 14 Feb 2018 12:00:55 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031820AbeBNPus (ORCPT + 99 others); Wed, 14 Feb 2018 10:50:48 -0500 Received: from mail.kernel.org ([198.145.29.99]:32838 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1031713AbeBNPuq (ORCPT ); Wed, 14 Feb 2018 10:50:46 -0500 Received: from mail-qk0-f177.google.com (mail-qk0-f177.google.com [209.85.220.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 49826217B6; Wed, 14 Feb 2018 15:50:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 49826217B6 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=robh+dt@kernel.org Received: by mail-qk0-f177.google.com with SMTP id i184so16092123qkf.10; Wed, 14 Feb 2018 07:50:46 -0800 (PST) X-Gm-Message-State: APf1xPA5q1O7Z1PZQZ1UnDJmXP0FW5IAsFCXDLcsuCr3gOc07daTKpc5 g7sQzmzO537KTRLR9lr74q8u5bwEq0bznDDnyg== X-Received: by 10.55.104.68 with SMTP id d65mr7917550qkc.306.1518623445365; Wed, 14 Feb 2018 07:50:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.245.147 with HTTP; Wed, 14 Feb 2018 07:50:24 -0800 (PST) In-Reply-To: <75515998-10e0-5025-7828-649112231067@gmail.com> References: <1518416868-8804-1-git-send-email-frowand.list@gmail.com> <6e967dd4-0fae-a912-88cd-b60f40ec0727@gmail.com> <75515998-10e0-5025-7828-649112231067@gmail.com> From: Rob Herring Date: Wed, 14 Feb 2018 09:50:24 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] of: cache phandle nodes to reduce cost of of_find_node_by_phandle() To: Frank Rowand Cc: Chintan Pandya , devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 13, 2018 at 7:00 PM, Frank Rowand wrote: > Hi Rob, > > On 02/11/18 22:56, Frank Rowand wrote: >> Hi Rob, >> >> On 02/11/18 22:27, frowand.list@gmail.com wrote: >>> From: Frank Rowand >>> >>> Create a cache of the nodes that contain a phandle property. Use this >>> cache to find the node for a given phandle value instead of scanning >>> the devicetree to find the node. If the phandle value is not found >>> in the cache, of_find_node_by_phandle() will fall back to the tree >>> scan algorithm. >>> >>> The cache is initialized in of_core_init(). >>> >>> The cache is freed via a late_initcall_sync() if modules are not >>> enabled. >>> >>> Signed-off-by: Frank Rowand >>> --- >>> >>> Changes since v1: >>> - change short description from >>> of: cache phandle nodes to reduce cost of of_find_node_by_phandle() >>> - rebase on v4.16-rc1 >>> - reorder new functions in base.c to avoid forward declaration >>> - add locking around kfree(phandle_cache) for memory ordering >>> - add explicit check for non-null of phandle_cache in >>> of_find_node_by_phandle(). There is already a check for !handle, >>> which prevents accessing a null phandle_cache, but that dependency >>> is not obvious, so this check makes it more apparent. >>> - do not free phandle_cache if modules are enabled, so that >>> cached phandles will be available when modules are loaded >> >> < snip > >> >> >> >> In a previous thread, you said: >> >>> We should be able to do this earlier. We already walk the tree twice >>> in unflattening. We can get the max phandle (or number of phandles >>> IMO) on the first pass, allocate with the early allocator and then >>> populate the cache in the 2nd pass. AIUI, you can alloc with memblock >>> and then free with kfree as the memblock allocations get transferred >>> to the slab. >> >> And I replied: >> >> Thanks for pointing out that kfree() can be used for memory alloced >> with memblock. I'll change to populate the cache earlier. >> >> >> I started to make this change when I moved forward to v4.16-rc1. There >> are two obvious ways to do this. > > < snip > > > And I did not finish the explanation, sorry. I meant to finish with saying > that given the drawbacks that I ended up not making the change for v2. > > While modifying the patch to respond to the v2 comments, I decided to go > ahead and try using memblock to alloc memory earlier. The result I got > was that when I tried to kfree() the memory at late_initcall_sync I got > a panic. The alloc function I used is memblock_virt_alloc(). You mention > "slab" specifically. Maybe the problem is that my system is using "slub" > instead. Dunno... Maybe memblock_free() still works? Or there's something else that needs to be done to transfer them. In any case, I guess doing it later is fine. And by slab, I mean the allocator, not the implementation (which can be slab, slub, or slob). Rob