Messages in this thread | | | Date | Thu, 18 Mar 1999 23:46:57 +0530 (IST) | From | V Ganesh <> | Subject | Possible optimization in ext2_file_write() |
| |
Hi, it looks like whenever we write a partial block which doesn't exist in the buffer cache, ext2_file_write() (and possibly the write functions of other filesystems) directly reads that block from the block device without checking if it is present in the page cache. in that case we can avoid a read and do a memcpy instead, with a function very similar to update_vm_cache(). This behaviour would severely affect applications doing small writes on areas which they (or someone else) has already done a read() or mmap-faulted into the page cache. The question is, are there any significant applications which do this ? It's very easy to tickle this problem: write a program which reads 1024 bytes, lseeks -1024, writes a byte and lseeks 1023. Running this program on a 486/100 MHz, 16 MB RAM, 64 MB file gives the following
0.96user 48.19system 5:14.41elapsed 15%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (16482major+11minor)pagefaults 0swaps plain 2.2.3
1.25user 44.00system 1:37.11elapsed 46%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (16441major+11minor)pagefaults 0swaps 2.2.3 patched to workaround the above problem.
Of course, typical UNIX programs/shell jobs don't indulge in this kind of behaviour. General workstation usage (X, kernel compiles etc.) for a day caused only 32 unnecessary reads. So unless there are any specific application categories which require this I guess it's not worth the trouble to patch.
Anyone working on a VM revamp or buffer/page cache unification ?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |