Received: by 10.223.185.116 with SMTP id b49csp6537294wrg; Wed, 28 Feb 2018 11:06:29 -0800 (PST) X-Google-Smtp-Source: AH8x227a01ZA9W9GkiFlFjR+4oMrL5Ceb5BJ73U8jbqKB158oFAAEEArpNv78+PPUVXfPtssqHoJ X-Received: by 10.167.129.67 with SMTP id d3mr18705595pfn.108.1519844789545; Wed, 28 Feb 2018 11:06:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519844789; cv=none; d=google.com; s=arc-20160816; b=kw5pFN7Wl33tZ3YVH4UrXfbzf453G+LLvSO8KpX63okEUJi9TJu6Jffq8ea4gTnqZp RoL9ObPDVfFwQ2LFJbXmuIV0Mo1juNXmKAt3wD0dO7+354WDZ1/Rbilz0qjsOfkFcuUg 9LAIsDeZu6cc6VZ22041f/NZ+a2Wh+DU20sIBX2H22nEy8Cv8n6JB/HWeNsxebei9WBU ZF1Y69IlB+T4PUUgyLKZXd1R07qee1f47C02DoKL6IDQF7BCX+YR9F85GaFw47oR+nFf XQFIU5R8G2kdn2W/tbIACZc/OsIIF1/hV46jKVX4UpydTPWhmURUr2858kR4V14IoSci SaTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=jsZhYcbcg7npy1jyBAkAYCTuImmjfeWku+I5tAXS0aI=; b=RUpmqqcPysnjmSLTsEpmVyxauBwlp8ibcMDOCngoYVepLQY5Xzezi4thvyadKjLoiY MyjYACf5ThtGSB5AWSNqtftlfTOejpkHdzo4xo2KTdZ147RiWMU+JUEXtSwXL+fV/ioh kyGc51a7meNb4/VKQjlSfcT2McQmtBY5XmXJa2IwHs5ZdXwb1dNtpdIO/4Q7ZY7n3ZIj mwJ/C1YnQxriaQozJYKv/jaeSDqDltRhyOPIHDO8vLaFr7JJzOaII2dtFtsNLoy7ia6v /ON/m/zPfp7zWCzTHQ27RqQvL+McefOnDP0HHMsI09fcjRfuhIQdwdiQhIiu7uE0TzYI pQlA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=XktyGLDJ; 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 j11si678117pfi.57.2018.02.28.11.06.14; Wed, 28 Feb 2018 11:06:29 -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=XktyGLDJ; 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 S933014AbeB1TFG (ORCPT + 99 others); Wed, 28 Feb 2018 14:05:06 -0500 Received: from mail-pl0-f65.google.com ([209.85.160.65]:47046 "EHLO mail-pl0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932088AbeB1TFE (ORCPT ); Wed, 28 Feb 2018 14:05:04 -0500 Received: by mail-pl0-f65.google.com with SMTP id y8-v6so2063878pll.13; Wed, 28 Feb 2018 11:05:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=jsZhYcbcg7npy1jyBAkAYCTuImmjfeWku+I5tAXS0aI=; b=XktyGLDJdEqRFpqqdkon7oE3HeatQRkKAuBuvRxgWdrgB3XvTEAm8pvKSJUUNn9+YV Ae411aHGSe6U6mrdgkD+ka7SFjMzQmyKx+sNgX+WgVoPTBbbqfH78NSloP7r4DMSMKQN MJjBJZgCMaLSrfM2JtDT7Og6AlPkxh9yTfexTWeznCgaJw85zYisMjqH50ZcMUkYF39x VVFcptSFdQsgz2rsB2VwvhxPooiE5RG8U1XDMtJoaWQiSLR7ryT+EXvg901pqPu79WO2 ZFP9w+THQYh0mlWEDVO3+jcwdICFlxXSge81S1YuqFM6jOnXs2QEoLn/PalGy6JkVnvF tPTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=jsZhYcbcg7npy1jyBAkAYCTuImmjfeWku+I5tAXS0aI=; b=rWHjehFRbxqCfg5M4TBcIxH4Ad9p719KANw173sSZU4SvMbKzbIizVPxjan3Qg8vRo rLqkcGi4yP+NcTYesEfWRCegWLD4IEzHTVH0htq0nXTtpeuOj/VpS9BnPkhDeLA57s28 mwWKVlgG81BNyoU4Fnl3ZMwXJwfLZNRc7eQGQ2iO4Qz2EBZRVVAyDL58JjxbWtKCshAa mNwtDHYAZnc83GrXeIVYDngXf+2eiDtVQjUzEIWgBI3H+uCOhioIdxIyMr5pyyM2LTnE hYSPQcWnFUiaoQ+EWdN/Qs3BExXSP+zKO4geH/OmaHANklhcqlvk/ptd7fhzvzjR4GIY YF2g== X-Gm-Message-State: APf1xPDxGIjGNeXIX/hFkc8Dan9pcF7702Pm6aeEzgVQclhvcmnlqdgB pOaO88bbHCHbhhi9/StA3dQ= X-Received: by 2002:a17:902:b686:: with SMTP id c6-v6mr18926602pls.339.1519844703833; Wed, 28 Feb 2018 11:05:03 -0800 (PST) Received: from localhost.localdomain (c-73-93-215-6.hsd1.ca.comcast.net. [73.93.215.6]) by smtp.gmail.com with ESMTPSA id m22sm5027462pfg.188.2018.02.28.11.05.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 28 Feb 2018 11:05:03 -0800 (PST) From: frowand.list@gmail.com To: Rob Herring , cpandya@codeaurora.org Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v4 0/2] of: cache phandle nodes to reduce cost of of_find_node_by_phandle() Date: Wed, 28 Feb 2018 11:04:14 -0800 Message-Id: <1519844656-16443-1-git-send-email-frowand.list@gmail.com> X-Mailer: git-send-email 1.9.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Size and performance data is in patch 1/2 comments Changes since v3: - of_populate_phandle_cache(): add check for failed memory allocation - add patch 2/2 into series instead of as a standalone patch that was dependent on patch 1/2 of this series Changes since v2: - add mask to calculation of phandle cache entry - which results in better overhead reduction for devicetrees with phandle properties not allocated in the monotonically increasing range of 1..n - due to mask, number of entries in cache potentially increased to next power of two - minor fixes as suggested by reviewers - no longer using live_tree_max_phandle() so do not move it from drivers/of/resolver.c to drivers/of/base.c 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 Frank Rowand (2): of: cache phandle nodes to reduce cost of of_find_node_by_phandle() of: add early boot allocation of of_find_node_by_phandle() cache drivers/of/base.c | 119 ++++++++++++++++++++++++++++++++++++++++++++++-- drivers/of/fdt.c | 2 + drivers/of/of_private.h | 5 ++ drivers/of/resolver.c | 3 -- 4 files changed, 122 insertions(+), 7 deletions(-) -- Frank Rowand