Messages in this thread | | | Date | Mon, 27 Feb 2006 00:50:43 +1100 | From | Nick Piggin <> | Subject | Re: Drastic Slowdown of 'fseek()' Calls From 2.4 to 2.6 -- VMM Change? |
| |
Ingo Oeser wrote: > On Saturday, 25. February 2006 06:16, Andrew Morton wrote: > >>runs like a dog on 2.6's reiserfs. libc is doing a (probably) 128k read >>on every fseek. > > > Thats the bug. If I seek, I never like to have an read issued. > seek should just return whether the result is a valid offset > in the underlying object. > > It is perfectly valid to have a real time device which produces data > very fast and where you are allowed to skip without reading anything. > > This device coul be a pipe, which just allows forward seeking for exactly > this (implemented by me some years ago). > > >>- fseek is a pretty dumb function anyway - you're better off with >> stateless functions like pread() - half the number of syscalls, don't >> have to track where the file pointer is at. I don't know if there's a >> pread()-like function in stdio though? > > > pread and anything else not using RELATIVE descriptor offsets are not > very useful for pipe like interfaces that can seek, but just forward. > > There are even cases, where you can seek forward and backward, but > only with relative offsets ever, because you have a circular buffer indexed by time. > If you like to get the last N minutes, the relative index is always stable, > but the absolute offset jumps. > > So I hope glibc will fix fseek to work as advertised. > > But for the simple file case all your answers are valid. >
Not really. The app is not silly if it does an fseek() then a _write_. Writing page sized and aligned chunks should not require previously uptodate pagecache, so doing a pre-read like this is a complete waste.
Actually glibc tries to turn this pre-read off if the seek is to a page aligned offset, presumably to handle this case. However a big write would only have to RMW the first and last partial pages, so pre-reading 128KB in this case is wrong.
And I would also say a 4K read is wrong as well, because a big read will be less efficient due to the extra syscall and small IO.
-- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com
- 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/
| |