Received: by 10.223.185.116 with SMTP id b49csp2588035wrg; Mon, 12 Feb 2018 12:07:04 -0800 (PST) X-Google-Smtp-Source: AH8x224DxzxRCpqo/AbJVoiQ4SB5CkVx7ySgbVY4q7rXkbJGKO38Fle50RpRH8Y5I9sLVP1/QWhh X-Received: by 2002:a17:902:6908:: with SMTP id j8-v6mr11597505plk.211.1518466023939; Mon, 12 Feb 2018 12:07:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518466023; cv=none; d=google.com; s=arc-20160816; b=s8SwIrYmujauwLM9tlNWk6K7hc6IBfc0k6PMzfFqVBwrSP169so3YoLfmU0uvRD+7i MOuMTlNUmX0NBADFf1drbmRPPyyLrnB3y+wlhnKGdu5KeruJwiRLfh+/7D+6nTU6u7cD 1Wx3jKF1jq0Cl+ZMSbESRmbTXEQ2e+s7J4HS9tjgzaBvvK+RjX3D3xHO9W0ppeUioipg BfDkl1HnI2DGSRRTVsCPEBpp/J+wxanoI5lqcBxo/WYJ3S+jeAdugJd3FBDcFMoD8o6b aAHMY03Xl7P5GiKzK+aOilqRq5CNS3c7RB/xeshVDFUPsx1GRGP7b/nMzE5gYGc14i8a wHqQ== 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:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=DO7HKqHwb39Z+3tK/C6LqdipuElchTP4GAYvG3/DEcY=; b=WEDS73BBj10WzcRWIM4nw8Nfo5d2E99BXsVnkaSzx/Mv/THYNoTlFp9Vzei9BRVED2 mIjbC5MiUmUjgOGBYZy5pLuRCWw0MwMtpD4YC+mTRHRr6c8HY9DVBSWUyOmgw2Jndyud 1XyzeZW8BRaB0ciVrUAo+JQtGduBF4p03q8QjgeesNgsyNJh8TRRsD2okGyyFP9RbFn6 vSUJRuNio94nEnUZ4c8s+X7tufsKrByQhMcsSWp6QoDXxpZmicR93MidsUM2qqTxG9hr qVbFSrNJoqRJyyhPHpVsmLd03+TtWUg3m4BAhPaMagzO86KahWVb7JU2bIxvywjGjg8N Kylw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=h98mgqOB; 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 x10-v6si255691plm.261.2018.02.12.12.06.48; Mon, 12 Feb 2018 12:07:03 -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=h98mgqOB; 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 S1752410AbeBLUGG (ORCPT + 99 others); Mon, 12 Feb 2018 15:06:06 -0500 Received: from mail-pg0-f68.google.com ([74.125.83.68]:42688 "EHLO mail-pg0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751202AbeBLUGE (ORCPT ); Mon, 12 Feb 2018 15:06:04 -0500 Received: by mail-pg0-f68.google.com with SMTP id y8so977115pgr.9; Mon, 12 Feb 2018 12:06:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=DO7HKqHwb39Z+3tK/C6LqdipuElchTP4GAYvG3/DEcY=; b=h98mgqOBhq69bfUD3GSzzWDoUL+dqC+UR7SkFLRYRMtQ0R81cTcV3zO05fvjIPD5JF ukVOqOs2bfB9Wjmby+TpfTpJOr9dkXvRlp//5eOEKGUAgMioPd9HKEAM/VxkdCrNt5SQ 3RiUwTuVUUXi0CptSe7uhldRdHzygChqpDxOlCKM/lTJ6K/RpuZctZ9MQlX/LyCkrQtu Lc+94agfTZN6Tj3+3K8DCzgNPcqzMK7DF3omguGwDzPhZYAI/2nJV2uiomj/5d7BJtto 1AtwVo/CQTnHzT6khOM4JUV+I9u4QqhMT2Wm37WHkWuXrzJboUPX/Ta4lpKPXYuCsvWZ 9PzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=DO7HKqHwb39Z+3tK/C6LqdipuElchTP4GAYvG3/DEcY=; b=dUmAme4vZJKbcXSenyL6YldbP2Eo0jiEaaK0v5lfsUC/DeSNDAClFMuId+vV0ofln9 y2wRmaTnkXHz87Yru7tQB5jOpLmjrxc9JuQ6xb7B7bEdiz64u1J+pHB9rY7gd9dekq/e ePsgXRHy4RnT4nB+hRbMjmjyuY2oVpLpa0Ynvz2LgZbaMFKab2KGaKdUr5tXRLouz1s4 fdMST0UpXO08+be9MzlYjc2wH4Za69lFHgyZ7ZfsO2HBmJUuY8btEsXAgsMiGurfwgBC 4htqGbhTUXmOTKs5OO9UOwCiF5IqGtAkCRZJMF36WfgaEC8V44QLQ7WNknO4UEfWdpaq KH8Q== X-Gm-Message-State: APf1xPBVzV46CdMUIkcLSO5pCZGJFhPHbkdZ1MN/Ko/YhVGuLR6eA7DM hEZUq4ZjULrFK59CxXKRJs8rfjQQ X-Received: by 10.101.78.143 with SMTP id b15mr3020136pgs.229.1518465963595; Mon, 12 Feb 2018 12:06:03 -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 k7sm22320542pgo.31.2018.02.12.12.06.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Feb 2018 12:06:02 -0800 (PST) Subject: Re: [PATCH v2] of: cache phandle nodes to reduce cost of of_find_node_by_phandle() To: Rasmus Villemoes , 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> <5ca5194d-8b87-bcb6-73ca-a671075e4704@prevas.dk> From: Frank Rowand Message-ID: Date: Mon, 12 Feb 2018 12:06:01 -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: <5ca5194d-8b87-bcb6-73ca-a671075e4704@prevas.dk> 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 On 02/12/18 00:58, Rasmus Villemoes wrote: > On 2018-02-12 07: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. > > Maybe a few words about the memory consumption of this solution versus > the other proposed ones. The patch comment is about this patch, not the other proposals. Please do not take that as a snippy response. There were several emails in the previous thread that discussed memory. In that thread I responded as to how I would address the concerns. If anyone wants to raise concerns about memory usage as a result of this version of the patch they should do so in this current thread. > Other nits below. > >> +static void of_populate_phandle_cache(void) >> +{ >> + unsigned long flags; >> + phandle max_phandle; >> + u32 nodes = 0; >> + struct device_node *np; >> + >> + if (phandle_cache) >> + return; > > What's the point of that check? Sanity check to make sure a memory leak of a previous cache does not occur. I'll change it to free the cache if it exists. There is only one instance of of_populate_cache() being called, so this is a theoretical issue. I intend to add another caller in the devicetree overlay code in the future, but do not want to do that now, to avoid a conflict with the overlay patch series that has been in parallel development, and for which I submitted v2 shortly after this set of patches. > And shouldn't it be done inside the > spinlock if at all? Not an issue yet, but I'll keep my eye on the possibility of races when I add a call to of_populate_cache() from the overlay code. >> + max_phandle = live_tree_max_phandle(); >> + >> + raw_spin_lock_irqsave(&devtree_lock, flags); >> + >> + for_each_of_allnodes(np) >> + nodes++; > > Why not save a walk over all nodes and a spin_lock/unlock pair by > combining the node count with the max_phandle computation? But you've > just moved the existing live_tree_max_phandle, so probably better as a > followup patch. I'll consider adding the node counting into live_tree_max_phandle() later. The other user of live_tree_max_phandle() is being modified in my overlay patch series (see mention above). I don't want to create a conflict between the two series. >> + /* sanity cap for malformed tree */ >> + if (max_phandle > nodes) >> + max_phandle = nodes; >> + >> + phandle_cache = kzalloc((max_phandle + 1) * sizeof(*phandle_cache), >> + GFP_ATOMIC); > > Maybe kcalloc. Sure, you've capped max_phandle so there's no real risk > of overflow. OK, will do. >> + for_each_of_allnodes(np) >> + if (np->phandle != OF_PHANDLE_ILLEGAL && >> + np->phandle <= max_phandle && >> + np->phandle) > > I'd reverse the order of these conditions so that for all the nodes with > no phandle we only do the np->phandle check. Also, extra whitespace > before &&. Will do. >> + phandle_cache[np->phandle] = np; >> + >> + max_phandle_cache = max_phandle; >> + >> + raw_spin_unlock_irqrestore(&devtree_lock, flags); >> +} >> + > > Rasmus >