![]() | ||||||||||
Messages in this thread |
Hi! On Mon, 5 Aug 2002, Oleg Drokin wrote: > Hello!> > On Sun, Aug 04, 2002 at 06:09:34PM +0200, Roland Kuhn wrote: > > > The first call to getdents64 takes 4.7s! I captured the task status and > > got this:> > It seems that your kernel performs writes slowly.> That's true only in the case of a "filled write queue" (I don't know exactly how it's working). However, I verified that the average SCSI command takes less than two seconds to complete in this case (time between send to card and receive response interrupt). BTW: was it directly clear for you for what the do_journal_begin_r() was waiting? I'm not so familiar with fs coding, especially the locking... While we're at it: it looks like e.g. the 3ware driver is busy waiting in tw_scsi_queue() until (by virtue of an interrupt?) a request_id becomes free. Is this common practice? Or is there code somewhere checking for the availability of these request slots before calling scsi_queue? I would think that the CPU can do more useful things while waiting for an interrupt... > > this is to use a sync mount, and there I discovered something really > > strange: 2.4.19 gives me about 17MB/s while 2.4.18-3 (RedHat) was creeping > > slow with 10kB/s!> > 2.4.18-3 is particularly bad know for this exact problem (slow write speed), > you should consider upgrading to at least 2.4.18-5 kernel from redhat updates. > > For me on plain 2.4.18 the problem is not visible that bad as for you. > I.e. ls on a directory where I write this big file finishes in under > half a second.> Do you use IDE or SCSI? It seems like the SCSI drivers can have up to 255*256 sectors pending on the controller. If that's the problem, how can I decrease this buffering? > > If you have any thoughts on the cause of this behaviour and/or on how to > > fix it, I would be glad to hear them. If it's not too complicated I could > > even code something up myself, and I for sure can do any testing needed.> > You said 2.4.19 writes stuff faster for you, how about testing ls on that > kernel?> The call trace was from 2.4.19, and the situation actually was much better than in the 2.4.18-3 case, where it took about 1 minute for ls to come back. Ciao, Roland +---------------------------+-------------------------+ | TU Muenchen | | | Physik-Department E18 | Raum 3558 | | James-Franck-Str. | Telefon 089/289-12592 | | 85747 Garching | | +---------------------------+-------------------------+ - 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/ | |||||||||
| Last update: 2005-03-22 12:27 [from the cache] ©2003-2008 | ||||||||||