Received: by 10.213.65.68 with SMTP id h4csp673195imn; Fri, 23 Mar 2018 13:07:48 -0700 (PDT) X-Google-Smtp-Source: AG47ELusQVH83ngzJJ+h0qBWWT4j0U0Dfu2+Lqe6fZqTOKdghOmxVDLlT/eVxoTElScaSSpPHU8N X-Received: by 2002:a17:902:7142:: with SMTP id u2-v6mr30627036plm.257.1521835667968; Fri, 23 Mar 2018 13:07:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521835667; cv=none; d=google.com; s=arc-20160816; b=0VnCZPp/wgCMlCUYjXzu7CIbpbeLrbMXdqI51TfM/u7IvZxo5s9gpnbbqNyWGgmzqs IEwGKH5LVH2Th0G+rwmXM5q457/aGBoT7c6XpMBiu6ccdNRLpSqM01m1vtorrvLLXxvN FIv8Fi0Ac8aQZDTFxY0a9Qjm0ruY2GAZkUgnKPeuCtWPfeUM58Qf/ZuI3FNr0mxWzXjY oF+EhNuz8UqVmOpioHFKRbqyLqQlnXwmRcX2hZAVSGYaLO0DUAyWH2yDyYVSTcilC3cg O/KbocsflDmb/mc0fpo7IRlLu8FbnYKtYuohWhdQ1vIed43lquwXY4ln4yQ57e+6pLk+ oAkA== 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=kuBeNi9hIDNQv3W8k9HYsh+HAXSHfOwMqNtG+umFE/k=; b=cBwZDOHCc6tMMKrdTiqbkujN/IFzQMVMorD/LHSW2wqrrY0mVaodaqqQ3ZZwhMZNxB 198wzpLCdNMFF5/2/p86nkhaqgzURkTsftithfBYEjdmIvxB1VigEdT4RWjejlK80tCb Jy2NbwnFzesismuBVrfvPnLTguUCpDr3DQYMQCnUDcAuc/ACltyBEtuCjJdjdwQvE2XC sj0gvCsfE42c8Is/48TlZa3gWL6pvU6SorCXlkR+G5yFT+/iX6LM4S3VlY82mADoB9lC swUc1tYHVlQ+O6nhN1N6BrrHMYjsQol2vRBhA4DLPxfDgYSFvyZyJ3nnh+st7Mfj6PaZ 4GFQ== 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 r68si7393441pfi.413.2018.03.23.13.07.33; Fri, 23 Mar 2018 13:07:47 -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 S1751987AbeCWUGY (ORCPT + 99 others); Fri, 23 Mar 2018 16:06:24 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:53860 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751595AbeCWUGW (ORCPT ); Fri, 23 Mar 2018 16:06:22 -0400 Received: from akpm3.svl.corp.google.com (unknown [104.133.9.71]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 350B0F11; Fri, 23 Mar 2018 20:06:22 +0000 (UTC) Date: Fri, 23 Mar 2018 13:06:20 -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: <20180323130620.7d60fc442463ed5c21898387@linux-foundation.org> In-Reply-To: <20180323031013.GB11150@localhost.localdomain> References: <20180322033722.9279-1-bhe@redhat.com> <20180322033722.9279-2-bhe@redhat.com> <20180322152929.9b421af2f66cc819ad691207@linux-foundation.org> <20180323005845.GA25740@localhost.localdomain> <20180322190606.859a0f1c7e2d1b2958daeb9f@linux-foundation.org> <20180323031013.GB11150@localhost.localdomain> X-Mailer: Sylpheed 3.6.0 (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 11:10:13 +0800 Baoquan He wrote: > On 03/22/18 at 07:06pm, Andrew Morton wrote: > > 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?). > > Yes. It doubles the memory consumption. > > AFAIK, the biggest number of resrouces I heard of possibly is mentioned > in this user space kexec_tools commit. In this commit, Xunlei told on > SGI system with 64TB RAM, the array which we have been using to store > "System RAM"|"Reserved"|"ACPI **" regions is not big enough. In that > case, we need extra 8Byte*2048=16KB at most. With my understanding, this > increase is system wide, since each resource instance only needs its own > list_head member, right? Yes. That sounds perfectly acceptable. It would be interesting to see what this approach looks like, if you have time to toss something together?