Re: The performance and behaviour of the anti-fragmentation related patches

Christoph Lameter
2007-03-02T05:50:36Z

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.