Received: by 10.223.185.116 with SMTP id b49csp80497wrg; Tue, 13 Feb 2018 17:01:44 -0800 (PST) X-Google-Smtp-Source: AH8x224khfOm6eVxs1V036mvKZ8u4TO+Cv1WwrPNK5oW4k8hNm9CUqcTKrDKQccFu+CW61d/w6gc X-Received: by 2002:a17:902:8ec4:: with SMTP id x4-v6mr2678833plo.271.1518570104245; Tue, 13 Feb 2018 17:01:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518570104; cv=none; d=google.com; s=arc-20160816; b=A0HAZDhHhvYGRm0tKeDHceYm9vauImXwqSlL2uzJB68cpXPrSyHu+xSnbBRWKBohdK Bsbw5twtpm0mj5IEA8BkwFfkpWDOWSD08d2uAcyHWEKtLSVjmVYecSuevVkUyLnq3yyl XLIFiFRUPLCD+9oKYQWWxflCyPEeeqlmme0WLW3w97R1JoKG1D1gbOjf3kulYgLvCspf VkuT1U2Mq63rewvl8kFnjMy75rXzN4QuaCw1991kSFZniQ3S1NbCeQ+yQ/FPpxcvNphG k4Y+9R+eu071wwSmKUKEvX3NdebxTYTEEEFsY9ScBzkv0kioXY+dZKasuk0giGdjEshc DVIg== 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=cQUVaxPfH/eAeI+VzM1wjxYPI0DHrcBXnkSArHZdTVc=; b=q7yvAabAZxEavtG6JfNDzvOpfJNcY1HkNAhvcj+cICwnqQtkx0GHJ27qEOkRdXd4fI h4JAHSYJ6uTGAws0g96mixs5FeV4ovz7gsF1BxOHfX8cv5GghQ9dnfuDmFXbUULp1+PS 8d2cEiXZgh7GOAG7KCxpFQzO9HHDR/SdLN0QTwOpk2qAzGcQ8ZaGIKXvKO/cCP6G3woD A8RJIBxV/Qm+xf5JX+zVr3kY4PcbCBLxVilDArBI9G5E6Gf5iJUmRNGZ4MFTR8sFDoGe +onKQyNjvoh5YyKnGLP/MGcot1RibnMHE+Mpe+WFMdhg3B437BbyFtlvoSGwhziVM1qW EMyA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=AA0NKeuM; 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 z12si5437034pgs.167.2018.02.13.17.01.28; Tue, 13 Feb 2018 17:01:44 -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=AA0NKeuM; 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 S966310AbeBNBAt (ORCPT + 99 others); Tue, 13 Feb 2018 20:00:49 -0500 Received: from mail-pl0-f65.google.com ([209.85.160.65]:37225 "EHLO mail-pl0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966220AbeBNBAr (ORCPT ); Tue, 13 Feb 2018 20:00:47 -0500 Received: by mail-pl0-f65.google.com with SMTP id ay8so7574646plb.4; Tue, 13 Feb 2018 17:00:47 -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=cQUVaxPfH/eAeI+VzM1wjxYPI0DHrcBXnkSArHZdTVc=; b=AA0NKeuMlk/61Qn5OKsa47g0tBilN1zcOZv36Ue9nVqsLwvXzvJhPCRc4IhH0Hx+WJ ZxFDnIUlyaofAKH6y9vyagQyJXxAmWjdywe1JpOwacK0yUgvTUgbJFirQS8I1SLOmIaV lETSxInKtaiWlsMW3Q4i927mSQ0LR95Sx4XCsSCAfEmuxGuZpm3ujjcywXMfD5CtdjzA +ttwhzh7IDDYUz3M/NNIRoRZpalxiqN57rj9C3Ke7wlMbFwXUeJ5Nw/HI2fTRxBU38Ie rzw5FoZreWhK7r9L+iCttM4PQZsfKhL0fQb1BCZDqOB9CPK+MLKzIoZVH7qt12So+yTC R1dg== 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=cQUVaxPfH/eAeI+VzM1wjxYPI0DHrcBXnkSArHZdTVc=; b=aS7ulWFgx2TvoHz2WApxxzjpPY29qhxQAKR8KEgLCp4KTNl7ndYdOqE/Zp+JOxcfjJ SvGdDqzPebS4mnlF9BrBjOH1USOw48riLNNUf5q6RolyZ8OLIRLrOie0pEAM+m7aWwtM lOhhZKg6z7Gtk37ky3CpeGmUXn01G9Wa5PzEupiUgtaEpwB/HpgBilPKbZbWUUSmm9Iq vTUf3m5iXRDm/Z0RKMXw0zrmsuagawNygIZVZVYjNWnrbuKo4gqPjXO1m8uW3aexzeDv 9OhkDOscEm2LlBNlAdbkr8IkC1tvQUE2gtWFyZPyIaX/PEKwnZyd9GJzU06Uw7C0DM7H PulQ== X-Gm-Message-State: APf1xPA/0Cbq0H4tmiyDU9EsHCws9A0n97a6wQzmDmEsf+qXoz3T/U3P W77L5SQHN//0xd1R7l6W500= X-Received: by 2002:a17:902:3fa5:: with SMTP id a34-v6mr2846500pld.326.1518570047096; Tue, 13 Feb 2018 17:00:47 -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 c25sm30316984pfi.183.2018.02.13.17.00.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Feb 2018 17:00:46 -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> <6e967dd4-0fae-a912-88cd-b60f40ec0727@gmail.com> Message-ID: <75515998-10e0-5025-7828-649112231067@gmail.com> Date: Tue, 13 Feb 2018 17:00:44 -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: <6e967dd4-0fae-a912-88cd-b60f40ec0727@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: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... -Frank