On Fri, 2 Mar 2007, Nick Piggin wrote: > So what do you mean by efficient? I guess you aren't talking about CPU > efficiency, because even if you make the IO subsystem submit larger > physical IOs, you still have to deal with 256 billion TLB entries, the > pagecache has to deal with 256 billion struct pages, so does the > filesystem code to build the bios.
Re the page cache: It needs also to be able to handle large page sizes of course. Scanning gazillions of page structs in vmscan.c will make the system slow as a dog. The number of page structs needs to be drastically reduced for large I/O. I think this can be done with allowing compound pages to be handled throughout the VM. The defrag issues then becomes very pressing indeed. We have discussed the idea of going to kernel with 2M base page size on x86_64 but that step is a bit drastic and the overhead for small files would be tremendous. Support for compound pages already exists in the page allocator and the slab allocator. Maybe we could extend that support to the I/O subsystem? We would also then have more contiguous writes which will further speed up I/O efficiency. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
