Hello, Toshi. On Wed, Oct 09, 2013 at 05:58:55PM -0600, Toshi Kani wrote: > Well, there was a plan before, which considered to enhance it to a > memory device granularity at step 3. But we had a major replan at step > 1 per your suggestion. > > https://lkml.org/lkml/2013/6/19/73 Where? "3. Improve memory hotplug to support local device pagetable." How can the above possibly be considered as a plan for finer granularity? Forget about the "how" part. The stated goal doesn't even mention finer granularity. Are firmware writers gonna be required to split SRAT entries into multiple sub-nodes to support it? Is segregating zones further for this even a good idea? Adding more NUMA nodes has its own overhead and the mm code isn't written expecting it to be repurposed for segmenting the same NUMA node for hotplug underneath it. Maybe zoning is a viable approach. Maybe it is not. I don't know, but you guys don't seem to be too interested in actual long term planning while pushing for something invasive which may or may not be viable in the longer term, which can often lead to silly situations. It isn't even clear whether SRAT is the right interface for this. If it's gonna require firwmare writer's cooperation anyway, why not provide the information as extended part of e820? It doesn't seem to have much to do with NUMA or zones. The only information the kernel needs to know is whether certain memory areas should only be used for page cache. At this point, at least to me, it doesn't seem reasonably clear how this is gonna develop and the whole thing feels like a kludge, which can be fine too, but seriously if you guys wanna push for an invasive approach, it should really be backed by longer term plan, vision, justification and the ability to make the necessary changes in the various involved layers. Maybe I'm being too pessimistic but I feel that there are a lot missing in most of those areas, which makes it quite risky to commit to invasive changes. If the zone based kludgy appraoch is something meaningfully useful, I'd suggest to sticking to it at least for now. Some of it would be useful anyway and if it doesn't fan out the added maintenance overhead is fairly low. Thanks. -- tejun -- 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>