Ping. The original thoughts of this interface is to get the real size of the section. Then I thought it maybe more useful if it gives the address range of the section, so that we can know where the hole is. As Naoya said, I didn't consider NUMA situation. So if the interface helps, I could try to cover NUMA stuff in it. thanks, Sheng 在 2015/3/2 20:29, shengyong 写道: > > > 在 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 <shengyong1@xxxxxxxxxx> >> >> 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 "<node id> <start-end>" 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@xxxxxxxxx. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a> > > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>