Messages in this thread | | | Date | Tue, 28 Feb 2006 11:34:11 +1100 | From | Nick Piggin <> | Subject | Re: Drastic Slowdown of 'fseek()' Calls From 2.4 to 2.6 -- VMM Change? |
| |
Hans Reiser wrote:
>Sounds like the real problem is that glibc is doing filesystem >optimizations without making them conditional on the filesystem type. >
I'm not sure that it should even be conditional on the filesystem type... To me it seems silly to even bother doing it, although I guess there is another level of buffering involved which might mean it makes more sense.
>Does anyone know the email address of the glibc guy so we can ask him >not to do that? > >
Ulrich Drepper I guess. But don't tell him I sent you ;)
>My entry for the ugliest thought of the day: I wonder if the kernel can >test the glibc version and..... > >Hans > >Nick Piggin wrote: > > >>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. >> >> --
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/
| |