Messages in this thread | | | Date | Wed, 30 Apr 2003 14:22:20 -0700 | From | Andrew Morton <> | Subject | Re: [BENCHMARK] 2.5.68-mm3 with contest |
| |
Con Kolivas <kernel@kolivas.org> wrote: > > All the io-write based loads were affected.
Yup. Mainly because the large queue increases truncate latencies.
gcc needs to delete a file. truncate needs to wait on all in-progress writeout against that file before releasing the blocks. With the larger queue that takes a lot longer.
Could be fixed with a global buffer cache (leave the IO in progress against the freed block, only wait on it if the block is reallocated). But we don't have a global buffer cache.
Could be fixed with an IO cancellation capability at the request layer. has been discussed, is tricky.
Could be fixed by waiting on any pending IO at reallocation time at the disk request layer, not the buffercache layer. This could be made to work OK with the rbtree-based request lookup actually. But it'd hammer the heck out of the request lookup code and the lock contention on big SMP would be large.
Could be fixed by reducing the queue size again ;) This is what we'll do. There isn't a lot of benefit in the large queues. -mm3 really only has the big queue to demonstrate that the VM/VFS behaviour is now decoupled from queue size, and for people to play with it.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |