Received: by 10.213.65.68 with SMTP id h4csp1219054imn; Thu, 22 Mar 2018 19:10:27 -0700 (PDT) X-Google-Smtp-Source: AG47ELuKteSiIGLRoqCPhRTRYmeWVUc6YJcfLKgvLO7wsoWQ3RzeNP7ohXbV7QbVdHiQ+GIUe8Bl X-Received: by 2002:a17:902:6b08:: with SMTP id o8-v6mr3009910plk.369.1521771027558; Thu, 22 Mar 2018 19:10:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521771027; cv=none; d=google.com; s=arc-20160816; b=mfYsDJgHSu3NKSpELsHjxdugwLElW7baGxWPQrSFKp3z9T+exY2xA+UsN9bD29IiqC 1qXPIKN0ZRLrpl30lhtWzrIj5LiMk2KaW7Sjjjxld/uwiwowuh4yiu89yyvwPlC4hFAA onW7/Gv3b0xjKknOXYchUrx6OERCL/5x8f6EkUYtuYGABv64SaniXKpD7a1rsClan5pO FzPHYGZ+2iieaLrHcCxFn6iJACOz89NjtjhPcRgVPqF6QlmeqX3UWQz0SQ79S/7K3Gzb r2Lh/r85tGMyBXI2t0iuwY237cWNnd/b4J9Vwfqwuch34iKXH4NQqz1aVNdBnopmR6hy 9h1A== 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:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=I+HLZxJRmtAvKZcTWW05oE9V6J3f4Jz77KisxyXw+AA=; b=zU6RSryxjXZkm/atZ7I7yaFW2+sJIEj50XwZGJrNSKeoElSU3IkPVhewsvYPQLp7i0 QEwB7Dy4+ZliX8UfBaY3tNj8t4olPAr/UmWoZRsj9AQCzkL09eduUy9Q/rYiw7CNBWcn Jluy5FByyAntlwjM+HW3zT2P5N53MS2FnH9xQWyoEkq1qGEB3gSNOdUXjs32svbwQXFa wwoXQikuxIaEh8Gk9G8prAlcZawWkqNWHJnzxbzpuP5Fgq/zLKwJG3Z5HHX6mPzL++kv 0BEB4/GtRo0XiifO5cCPRmK/QVf2G9yQSPKACBYdJGbw8NWAxjUd2K1wCHQGUom+FzjV e9rg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z13si5192433pgu.804.2018.03.22.19.09.26; Thu, 22 Mar 2018 19:10:27 -0700 (PDT) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751692AbeCWCGJ (ORCPT + 99 others); Thu, 22 Mar 2018 22:06:09 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:38374 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751551AbeCWCGI (ORCPT ); Thu, 22 Mar 2018 22:06:08 -0400 Received: from localhost.localdomain (c-24-4-125-7.hsd1.ca.comcast.net [24.4.125.7]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id D19061032; Fri, 23 Mar 2018 02:06:07 +0000 (UTC) Date: Thu, 22 Mar 2018 19:06:06 -0700 From: Andrew Morton To: Baoquan He Cc: linux-kernel@vger.kernel.org, kexec@lists.infradead.org, takahiro.akashi@linaro.org, ebiederm@xmission.com, vgoyal@redhat.com, dyoung@redhat.com, prudo@linux.vnet.ibm.com Subject: Re: [PATCH 1/2] resource: add walk_system_ram_res_rev() Message-Id: <20180322190606.859a0f1c7e2d1b2958daeb9f@linux-foundation.org> In-Reply-To: <20180323005845.GA25740@localhost.localdomain> References: <20180322033722.9279-1-bhe@redhat.com> <20180322033722.9279-2-bhe@redhat.com> <20180322152929.9b421af2f66cc819ad691207@linux-foundation.org> <20180323005845.GA25740@localhost.localdomain> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 23 Mar 2018 08:58:45 +0800 Baoquan He wrote: > > erk, this is pretty nasty. Isn't there a better way :( > > Yes, this is not efficient. > > In struct resource{}, ->sibling list is a singly linked list. I ever > thought about changing it to doubly linked list, yet not very sure if > it will have effect since struct resource is a core data structure. Switching to a list_head sounds OK. The only issue really is memory consumption and surely we don't have tens of thousands of struct resources floating about(?). Or if we do have a lot, the machine is presumably huge (hope?). > AKASHI's method is more acceptable, and currently only kexec has this > requirement. What method is that?