Messages in this thread | | | Date | Mon, 5 Aug 2002 11:22:49 +0200 (CEST) | From | Roland Kuhn <> | Subject | Re: reiserfs blocks long on getdents64() during concurrent write |
| |
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/
| |