Received: by 10.223.176.5 with SMTP id f5csp3567037wra; Mon, 29 Jan 2018 15:24:07 -0800 (PST) X-Google-Smtp-Source: AH8x226p+uIcqmQnOV1RVdM754sSoKYXilAmqdMym0NpXwP3v4OJM74gldepDPCXTuMKXh/RHFps X-Received: by 10.101.65.131 with SMTP id a3mr21662135pgq.99.1517268247584; Mon, 29 Jan 2018 15:24:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517268247; cv=none; d=google.com; s=arc-20160816; b=0cFVaATHGp6bN7CFF+LVlgy1vSRY4G3Zcka//4NUzd7F0BeSxEh+OXB5PIin9YFC7N 0qC3XZLka32PdUFyuOdIawNPMXqowOgudTrfwDHEeK/QWDJA5Z/OpfJyegGy2nCFM/dY p53a5GnfM8hQ2ELfddtSxkIF145hPI7dyl/SttreNGPZ3yk+SmHBN3d0UgCr+WLGFztM H8iyeLPEjiloasAGyiPHwNHTtdG0bB3y1JgTKgKz5Y47nO4zCSFwMILWtXdha+sAB+u9 jaYYamyxrhtAx4OLdi6jXZGyc4txDdHmULvVxFyc0bbPqXmBNj8dLTJxo0e5A+AfppFW LnSQ== 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=SRukf5Zr2tcub3laC+vLR1o65SUrKNvd2/s63EZVrso=; b=k3hWideWI/kVQ8NuLKtQ5JNvXlJ+21fG7o9JoRGEFpmMuXso4gdSm72BqU0N6+TQG3 wzVqIVkdYlsATEdPffKdnnV8njk43sQXplXfUaTOnmDdOvrq8w8uQKQl470xw71cazI3 KNkVZW7BYaHXsixk6GRa9oNL99UZ1oLjs7zWRLx8p3oAtmXXXJu47tbIUA3FRdXNmboT 8O9PSf7E1Hq3ymtMitX0UO+nDkCKVMOZGEE9qcvnBQvRbKvdYFDQc92jhty84lEtylUo OSu6skYutHVLCiTnB6akNS2EZpiG7jaEcIGUSvmZRRaWCx0bStB23m0oEdeB00Xq0nn1 0VhA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=LAzinffE; 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=NONE 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 43-v6si3633095plc.167.2018.01.29.15.23.52; Mon, 29 Jan 2018 15:24:07 -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=LAzinffE; 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=NONE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751907AbeA2XXR (ORCPT + 99 others); Mon, 29 Jan 2018 18:23:17 -0500 Received: from mail-pg0-f46.google.com ([74.125.83.46]:40222 "EHLO mail-pg0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751824AbeA2XXQ (ORCPT ); Mon, 29 Jan 2018 18:23:16 -0500 Received: by mail-pg0-f46.google.com with SMTP id g16so5678977pgn.7; Mon, 29 Jan 2018 15:23:16 -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=SRukf5Zr2tcub3laC+vLR1o65SUrKNvd2/s63EZVrso=; b=LAzinffE1DjbVmLId51rKcr+43rAXQV0+LHsKKLsYYimjDcNKXNZilfSlmdcQdDS3U qXDEGBgYOZuc+eXKseSMOnlHGn2iAGvY5dnXApve+GJk8/l4T1wjxSK3H0Ix6Cey7TCw P7EZ7HQjWvpbBdQYpLw03muV5I+K+wVH2GrjYafTMKK0SrVqt+mly1pPhgeqm9M+bUV7 mH8RS6zPQHPdFajqavDWPoakm34HID3j1uuHlqwBfOJyh5pqV7dUlTqvvc/mG71ldC82 1h9NvYjVxUTcY0mbIGRKB1AJBqAbXwCjqY2lfgbQVaBlerxvOsjb3E8y91xTUUgZcYV5 d+0g== 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=SRukf5Zr2tcub3laC+vLR1o65SUrKNvd2/s63EZVrso=; b=aFozvi6FYNnSxAr8SuNxc2l8+y7zSP7WnjSFTa5NPoWVQJ+6IhdR/ZktMf9VgjSdT4 DqNv+/8JzcZG6qgVnPMmt+A37D516GNMuqpF1TBn3CfyB+7bCeulz5CIERPSVhqZgr30 P4RSyVPA57VEZDsJTxJaeA2xuIb/eqnJw7i1DF3DNj4X5Mx8AZ4OMlIRAkKDentnlDs4 9oTOC0kci4YX1q5wHNklZYRHhRHuyX3T8QTNPH1kyLX4wm9NFZfDu1XIg7u7s8MoAVBI CtJL0Hr9n00XuS2l/53J1yqhCw921+dqQZGXQc6PF7Fplu1g1SB4lkUcjjQiWsXljrIb ulzg== X-Gm-Message-State: AKwxytfQTWSnuSSHXcYIOqMQD9AOQmwnrGXpgwpAdHnZwOcL3uiX+wYx f1d8M5dy6YYP6chEtYcuuDU= X-Received: by 10.101.80.69 with SMTP id k5mr11643053pgo.435.1517268195647; Mon, 29 Jan 2018 15:23:15 -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 c77sm34874090pfl.168.2018.01.29.15.23.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jan 2018 15:23:15 -0800 (PST) Subject: Re: [PATCH v2] of: use hash based search in of_find_node_by_phandle To: Chintan Pandya , robh+dt@kernel.org, devicetree@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org References: <1516955496-17236-1-git-send-email-cpandya@codeaurora.org> From: Frank Rowand Message-ID: <2d877704-47c5-c1fc-1b89-976cd9b1ccaa@gmail.com> Date: Mon, 29 Jan 2018 15:23:13 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1516955496-17236-1-git-send-email-cpandya@codeaurora.org> 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 Chintan, On 01/26/18 00:31, Chintan Pandya wrote: > of_find_node_by_phandle() takes a lot of time (1ms per > call) to find right node when your intended device is > too deeper in the fdt. Reason is, we search for each > device serially in the fdt. See this, > > struct device_node *__of_find_all_nodes(struct device_node *prev) > { > struct device_node *np; > if (!prev) { > np = of_root; > } else if (prev->child) { > np = prev->child; > } else { > /* Walk back up looking for a sibling, or the end of the structure */ > np = prev; > while (np->parent && !np->sibling) > np = np->parent; > np = np->sibling; /* Might be null at the end of the tree */ > } > return np; > } > > #define for_each_of_allnodes_from(from, dn) \ > for (dn = __of_find_all_nodes(from); dn; dn = __of_find_all_nodes(dn)) > #define for_each_of_allnodes(dn) for_each_of_allnodes_from(NULL, dn) > > Implement, device-phandle relation in hash-table so > that look up can be faster, irrespective of where my > device is defined in the DT. > > There are ~6.7k calls to of_find_node_by_phandle() and > total improvement observed during boot is 400ms. > > Signed-off-by: Chintan Pandya > --- > drivers/of/base.c | 8 ++++++-- < snip > I asked some questions in the version 1 thread and did not get answers. I am copying the 3 questions here. (1) >>> >> Please give me a pointer to the code that is doing >> this search. >> >> -Frank > You can refer include/linux/of.h > > #define for_each_of_allnodes_from(from, dn) \ > for (dn = __of_find_all_nodes(from); dn; dn = __of_find_all_nodes(dn)) > #define for_each_of_allnodes(dn) for_each_of_allnodes_from(NULL, dn) > > where __of_find_all_nodes() does > > struct device_node *__of_find_all_nodes(struct device_node *prev) > { > struct device_node *np; > if (!prev) { > np = of_root; > } else if (prev->child) { > np = prev->child; > } else { > /* Walk back up looking for a sibling, or the end of the structure */ > np = prev; > while (np->parent && !np->sibling) > np = np->parent; > np = np->sibling; /* Might be null at the end of the tree */ > } > return np; > } > Let me restate my question. Can you point me to the driver code that is invoking the search? (2) And also the .dts devicetree source file that you are seeing large overhead with. (3) -- this one is less important, but if the info is easily available to you Sorry about dribbling out questions instead of all at once.... What is the hardware you are testing this on? Processor? Cache size? Memory size? Processor frequency? Any other attribute of the system that will help me understand the boot performance you are seeing? Thanks, Frank