Messages in this thread | | | Date | Tue, 22 Jul 2003 09:59:57 -0400 | From | Andrea Arcangeli <> | Subject | Re: 2.4.22pre6aa1 |
| |
On Tue, Jul 22, 2003 at 03:34:16PM +0200, Marc-Christian Petersen wrote: > On Friday 18 July 2003 00:50, Andrea Arcangeli wrote: > > Hi Andrea, > > > Can you try to change include/linux/blkdev.h like this: > > -#define MAX_QUEUE_SECTORS (4 << (20 - 9)) /* 4 mbytes when full sized */ > > +#define MAX_QUEUE_SECTORS (16 << (20 - 9)) /* 4 mbytes when full sized */ > > This will raise the queue from 4 to 16M. That is the first(/only) thing > > that can explain a drop in performnace while doing contigous I/O. > > However I didn't expect it to make a difference, or at least not so > > relevant. > > If this doesn't help at all, it might not be an elevator/blkdev thing. > > At least on my machines the contigous I/O still at the same speed. > well, it doesn't help at all. I/O gets more worse with that change. (8mb/s > less). How can this happen? *wondering* > > > You also where the only one reporting a loss of performance with > > elevator-lowlatency, it could be still the same problem that you've > > seen at that time. > The only one? Surely not. Also Con tested your elevator-lowlatency and we both > saw performance degration :)
performance degradation when? note that we're only talking about contigous I/O here, not contest. I can't measure any performance degradation during contigous I/O and if something it could be explained by the now shorter queue, but you tried enlarging it and it went even slower (this was good btw, confirming a larger queue was completely worthless and it only hurts the VM without providing any I/O bandwidth pipelining benefit). The elevator-lowlatency should have no other effect other than a shorter queue during pure contigous I/O.
> > can you try with data=writeback (or ext2) or hdparm -W1 and see if you > > can still see the same delta between the two kernels? (careful with -W1 > > as it invalidates journaling) > Yes, I'll do it later this day.
please try plain ext2, this sounds like some fs effect of some sort. The fs must throttle on the shorter queue or seek differently somehow.
> Sorry for my late reply. I've been very busy.
No problem ;)
Andrea - 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/
| |