On Fri, 27 Jan 2012, Dan Magenheimer wrote: > Some (related) topics proposed for the MM track: > > 1) Optimizing the utilization of RAM as a resource, i.e. how do we teach the > kernel to NOT use all RAM when it doesn't really "need" it. See > http://lwn.net/Articles/475681/ (or if you don't want to read the whole > article, start with "Interestingly, ..." four paragraphs from the end). > > 2) RAMster now exists and works... where are the holes and what next? > http://marc.info/?l=linux-mm&m=132768187222840&w=2 > > 3) Next steps in the page replacement algorithm: > a) WasActive https://lkml.org/lkml/2012/1/25/300 > b) readahead http://marc.info/?l=linux-scsi&m=132750980203130 > > 4) Remaining impediments for merging frontswap > > 5) Page flags and 64-bit-only... what are the tradeoffs? Yes, this last one is something I want to discuss too. If page_cgroup hadn't grown so small, I'd be suggesting to squeeze some more flag bits (or better, the node/zone info) into the 32-bit struct page lru pointers. But with page_cgroup now ready to fit into the 64-bit struct page (which contains an empty field from SLUB's alignment demands), it might - might - be time to enlarge the 32-bit struct page slightly. Hugh -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>