o/~ There are many things that I would like to say to you ... o/~ mostly around MM and FS interaction. 1. Exploiting multiorder radix tree entries. I believe we would do well to attempt to allocate compound pages, insert them into the page cache, and expect filesystems to be able to handle filling compound pages with ->readpage. It will be more efficient because alloc_pages() can return large entries out of the buddy list rather than breaking them down, and it'll help reduce fragmentation. 2. Supporting filesystem block sizes > page size. Once we do the above for efficiency, I think it then becomes trivial to support, eg 16k block size filesystems on x86 machines with 4k pages. 3. Moving slab objects. I've been working with Christoph Lameter this week on implementing a reclaim operation for radix tree nodes. It seems feasible. We should probably talk about reclaming dentries and inodes as well. 4. Pretty much anything relating to DAX. See other thread. 5. I have discovered a newfound fascination with CIFS which is totally unrelated to my new employer. Honest. I should have some interesting patches for CIFS by LSFMM. 6. Overhauling vmap to use a radix tree instead of a possibly recursive vmalloc of an array to store pointers to the pages. 7. Using alloc_pages_exact() to kmalloc objects larger than PAGE_SIZE*2 8. Nailing down exactly what GFP_TEMPORARY means 9. Adding malloc()/free() as a kernel API I have more things in my IDEAS file, but I think that will do for now. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html