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/
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:26 EST