Received: by 10.223.185.116 with SMTP id b49csp1862251wrg; Sun, 11 Feb 2018 23:24:47 -0800 (PST) X-Google-Smtp-Source: AH8x224YPcdC8IZTO/G9HkVYj2Gh1osfmZP7sWN5xs012YEla6/1BxAb9G8x8jRGXNEwE++ahICf X-Received: by 10.98.98.1 with SMTP id w1mr10784778pfb.9.1518420287403; Sun, 11 Feb 2018 23:24:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518420287; cv=none; d=google.com; s=arc-20160816; b=euMnFlhx4FNenTXkkO2PJyqr4cyzjp+Hq5f0CkRhqkJr9l/lbN3Tcss7BYtMyReIdE /pIZY95Mzei9rZ+PX6Egb/Tn+gVljo0RUqj3ltA7PSDeNn/CWRr2PemMRktPUBchDiTf gQVY2rzhwCrMAoBjWCLrHCKUGqxHIOKchp8AzSwG8Pi+ellAkY1KIes1nPfoXOC0nxyY zbaI6y4MuhLcSePdhMEj6DuA+fP8Pm44e6dzrAfSBf/kxrCf/yp68pwrKNGSX+4oNbJu LsnIHxsz+mBtpKebsKo+yXJvGiV016OJJbLOKfPbORHNGocPWv9ubG8DO4zfk8seoib/ 2J6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:from:subject:dkim-signature :arc-authentication-results; bh=7RSZeu9DGlQr6NY1XZFLNJIkrKxcm0U7H9acgncAqQ8=; b=NkLzaK0ys7kCZptQUSinobY5MkBVraWPRrm3354zGXI88tbZm0wiyDbwWNGPUGWHr7 x61et2E8ZzPh1RM4Fc8xe7nnm+aJKoA1Xew2Fm3ci2cda/2tbUA5pZSDCo2nLZ9nQEym MjrOJ0a4l1bygdoODexHxk/Kc8m42hhW9JIRULSiv3rKGKbfMt1Fa0z8u8Nf50jfHUxb ksHxDNOCe683l/9RQbbLRNOIIkgKS8Kq7IRkPe1M+IQoubcbknREc769MarViRScu6va 20WoZummrw8JsAV1SZA7FgmsA3r7AUvXAyEFOeCDoEWlskPNQz1K+VtUBldA7+dW0pZv yRcA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=HKlZdCNL; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j190si336245pgd.315.2018.02.11.23.24.33; Sun, 11 Feb 2018 23:24:47 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=HKlZdCNL; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751441AbeBLG4r (ORCPT + 99 others); Mon, 12 Feb 2018 01:56:47 -0500 Received: from mail-it0-f66.google.com ([209.85.214.66]:51612 "EHLO mail-it0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751332AbeBLG4p (ORCPT ); Mon, 12 Feb 2018 01:56:45 -0500 Received: by mail-it0-f66.google.com with SMTP id 193so2646154iti.1; Sun, 11 Feb 2018 22:56:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=7RSZeu9DGlQr6NY1XZFLNJIkrKxcm0U7H9acgncAqQ8=; b=HKlZdCNL/NKXsIHidBGx0GMWWoG7TyIEU1aKG+9u0bVVkqDF5DZpUu4Suk2wblyCyb tfXymsRa81qh/w8adb2C74AOgYafGZ3Ck3XZZg2TQsWD76WDCOtcUKq8cWSK+FoZ3qNb iS46oo8/yXMvQupgplGV8Ihzx6Or1kPYasVwMKoEbodtvUJPu+OAyt4aVVCpHne+KgBw YiA0/AA0koq7fwSHPBgWMB/ZPqfZsXDtzdcK6U9HTf8++Zo4Qu2kW3oJ230ytXqA63XM qzwAyNK5Oa3pqsVECPndcb3LEk0bfJZ+tzAD4+E3vJkmpMjBcARJQkEKHA5uMSlidsYx UoGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7RSZeu9DGlQr6NY1XZFLNJIkrKxcm0U7H9acgncAqQ8=; b=AeDnl2SGBzO0sdg/+jDG3W/IRBg6hiBuJv8CKHp7Pw6aNQ/j17hFxyx4T2txnEmFXn /lpIOTyYWovb5QvOUYY414mJ8AJWBjY92fveLwlNn+IV/EGN7Eua0/VANSarImLi03lP Y3S64SdwS7vjEJpbeRecagZ4oeXyP6ZXYjW/ZMpJGCTooHm0deiU4XoAcDeb1M+0jE+D JMxmCmRwWnDDxD5AyjxLKgrlShjTo7PtRx56wDzPxKpGoeti0lr030pk4/o/2wdv7D/O kuqn+o9xWUjj19ICzFHECi0cVZ07+5jmLCwaeP49/9ztoe9Vt11HFV3G5TaSrHeKzoig +xYw== X-Gm-Message-State: APf1xPBdah3J1gryrveZQ/ogPROcKpInywrgUCazZWUlcQ9nvCTVNj6V Ro0dqr4v3hz2AMYMvbgSIRVuiL4Q X-Received: by 10.36.70.135 with SMTP id j129mr4240835itb.76.1518418604361; Sun, 11 Feb 2018 22:56:44 -0800 (PST) Received: from [192.168.1.70] (c-73-93-215-6.hsd1.ca.comcast.net. [73.93.215.6]) by smtp.gmail.com with ESMTPSA id c143sm6120500itb.23.2018.02.11.22.56.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Feb 2018 22:56:43 -0800 (PST) Subject: Re: [PATCH v2] of: cache phandle nodes to reduce cost of of_find_node_by_phandle() From: Frank Rowand To: Rob Herring , cpandya@codeaurora.org Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <1518416868-8804-1-git-send-email-frowand.list@gmail.com> Message-ID: <6e967dd4-0fae-a912-88cd-b60f40ec0727@gmail.com> Date: Sun, 11 Feb 2018 22:56:42 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1518416868-8804-1-git-send-email-frowand.list@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. The first is to create and populate the phandle cache during the two phases of unflattening. To do this would require counting the number of nodes to be unflattened and find the largest phandle value during phase 1, then allocate the cache before phase 2, then populate the cache during phase 2. This is not difficult, but it is intrusive. The second obvious way is to modify of_populate_phandle_cache() to use the early allocator if called early in the boot and call this immediately after unflattening. Then if of_populate_phandle_cache() is called later (eg for applying overlays) it would have to change to using kzalloc(). It did not seem like the larger overhead of the very few calls of of_find_node_by_phandle() before the slightly later phandle cache population justify adding the extra complexity in of_populate_phandle_cache(). -Frank