Messages in this thread | | | Date | Thu, 25 May 2006 13:28:38 -0700 (PDT) | From | David Lang <> | Subject | Re: [PATCH 00/33] Adaptive read-ahead V12 |
| |
> If the developers of that program want to squeeze the last 5% out of it > then sure, I'd expect them to use such OS-provided I/O scheduling > facilities. Database developers do that sort of thing all the time. > > We have an application which knows what it's doing sending IO requests to > the kernel which must then try to reverse engineer what the application is > doing via this rather inappropriate communication channel. > > Is that dumb, or what? > > Given that the application already knows what it's doing, it's in a much > better position to issue the anticipatory IO requests than is the kernel.
if a program is trying to squeeze every last bit of performance out of a system then you are right, it should run on the bare hardware. however in reality many people are willing to sacrafice a little performance for maintainability, and portability.
if Adaptive read-ahead was only useful for Postgres (and had a negative effect on everything else, even if it's just the added complication in the kernel) then I would agree that it should be in Postgres, not in the kernel. but I don't believe that this is the case, this patch series helps in a large number of workloads (including 'cp' according to some other posters), postgres was just used as the example in this subthread.
gnome startup has some serious read-ahead issues from what I've heard, should it include an I/O scheduler as well (after all it knows what it's going to be doing, why should the kernel have to reverse-enginer it)
David Lang
- 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/
| |