From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by kanga.kvack.org (Postfix) with ESMTP id 0F5F76B0038 for ; Mon, 2 Mar 2015 07:31:40 -0500 (EST) Received: by padfb1 with SMTP id fb1so4710333pad.7 for ; Mon, 02 Mar 2015 04:31:39 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com. [119.145.14.66]) by mx.google.com with ESMTPS id fj14si1436068pac.128.2015.03.02.04.31.35 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 02 Mar 2015 04:31:39 -0800 (PST) Message-ID: <54F457A5.3070602@huawei.com> Date: Mon, 2 Mar 2015 20:29:25 +0800 From: shengyong MIME-Version: 1.0 Subject: Re: [RFC PATCH 1/2] mem-hotplug: introduce sysfs `range' attribute References: <1425269100-15842-1-git-send-email-shengyong1@huawei.com> <20150302091714.GA32186@hori1.linux.bs1.fc.nec.co.jp> In-Reply-To: <20150302091714.GA32186@hori1.linux.bs1.fc.nec.co.jp> Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Naoya Horiguchi Cc: "akpm@linux-foundation.org" , "gregkh@linuxfoundation.org" , "nfont@austin.ibm.com" , "linux-mm@kvack.org" , "zhenzhang.zhang@huawei.com" , Dave Hansen , David Rientjes 在 2015/3/2 17:17, Naoya Horiguchi 写道: > # Cced some people maybe interested in this topic. > > On Mon, Mar 02, 2015 at 04:04:59AM +0000, Sheng Yong wrote: >> There may be memory holes in a memory section, and because of that we can >> not know the real size of the section. In order to know the physical memory >> area used int one memory section, we walks through iomem resources and >> report the memory range in /sys/devices/system/memory/memoryX/range, like, >> >> root@ivybridge:~# cat /sys/devices/system/memory/memory0/range >> 00001000-0008efff >> 00090000-0009ffff >> 00100000-07ffffff >> >> Signed-off-by: Sheng Yong > > About a year ago, there was a similar request/suggestion from a library > developer about exporting valid physical address range > (http://thread.gmane.org/gmane.linux.kernel.mm/115600). > Then, we tried some but didn't make it. Thanks for your information. > > So if you try to solve this, please consider some points from that discussion: > - interface name: just 'range' might not be friendly, if the interface returns > physicall address range, something like 'phys_addr_range' looks better. > - prefix '0x': if you display the value range in hex, prefixing '0x' might > be better to avoid letting every parser to add it in itself. I agree on these 2 suggestion. > - supporting node range: your patch is now just for memory block interface, but > someone (like me) are interested in exporting easy "phys_addr <=> node number" > mapping, so if your approach is easily extensible to node interface, it would > be very nice to include node interface support too. After reading the previous discussion, I think the content in the interface should look like " " to avoid overlay of memory node. Am I right? Then we could use `memory_add_physaddr_to_nid(u64 start)' to translate physical address to node id when the address is recorded to the ranges list in get_range(). The problem is that `struct resource' does not have an appropriate member to save the node id value, which is saved in resource->flags temporarily for testing. thanks, Sheng > > Thanks, > Naoya Horiguchi > . > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org