tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Scsipi guru needed...
Manuel Bouyer wrote:
> On Sun, Nov 30, 2008 at 07:41:05PM +0100, Anders Magnusson wrote:
>> Hi,
>>
>> I have been trying to find out why the performance of the ciss
>> controller (Compaq raid) in
>> DL38x is really bad, but as I don't understand anything about the scsipi
>> layer (are there any docs?)
>
> there is scsipi(9).
>
Yes, but I still got lost in all terminology. Better to ask :-)
>> I must ask around. All this is really strange.
>>
>> Writing data to the raw sd device (bs=64k) gets just over 7MB/s, which
>> is quite slow.
>> Some debugging showed that:
>> - A write transfer (from given to the ctlr to interrupt) takes 8ms. Ok,
>> no write cache on the ctlr maybe?
>
> So, with 64k every 8ms, the max write speed would be 8MB/s when using
> the raw device.
>
Exactly, that is as expected.
>> - Only one (1) active transfer at a time, even though the ctlr can have
>> 1024.
>
> Note that when using the raw device, you won't have more than one command
> submitted to sd(4) at a time.
>
Of course. I should have mentioned that this is a common behavior, not when
using the raw device.
>> Looking in sdstart it seems that periph_openings is 1, which means only
>> one at a time.
>> Increasing it to 40 (using ddb) makes the machine a little faster, but
>> not much.
>>
>> The config stuff in ciss.c to setup this seems correct to me, but
>> someone that understands
>> it may have some ideas...?
>
> One thing looks wrong in ciss:
> sc->sc_adapter.adapt_max_periph = sc->maxunits;
> adapt_max_periph is "number of commands the adapter can handle per device".
> So if the adater can handle 1024 commands per unit, it should probably be
> sc->sc_adapter.adapt_max_periph = sc->sc_adapter.adapt_openings
>
> Also our scsipi layer supports only 256 tag per device, and it's not
> clamped by the scsipi layer si it should probably really be
> sc->sc_adapter.adapt_max_periph = min(sc->sc_adapter.adapt_openings, 256)
>
Ok, thanks, I try that tomorrow.
>> It should be noted that FreeBSD works very well with this controller,
>> while NetBSD doesn't :-/
>
> Do you know what MAXPHYS does FreeBSD use ? 64k is very low for modern
> disk systems. I think the right thing for us would be to kill MAXPHYS
> and use per-device MAXPHYS, but it's not trivial.
>
No, I don't know, but it is far more than 64k. But that doesn't matter;
using bs=64k when dd:ing to the raw device gives much better performance
anyway. Besides, MAXPHYS should be fixed anyway.
-- Ragge
Home |
Main Index |
Thread Index |
Old Index