diskio low read performance

[Kris Kennaway]

On Sat, Jan 13, 2007 at 05:23:39PM -0200, Michel Santos wrote:

> >> kernel config
> >> http://suporte.lucenet.com.br/ms/kernel62
> >
> > options        SCHED_ULE               # ULE scheduler
> >
> > From the NOTES file from where you copied this:
> >
> > # SCHED_ULE is a new scheduler that has been designed for SMP and has some
> > # advantages for UP as well.  It is intended to replace the 4BSD scheduler
> > # over time.  NOTE: SCHED_ULE is currently considered experimental and is
> > # not recommended for production use at this time.
> >
> > When investigating problems with your system, your very first step
> > should be to revert the use of code marked "experimental" and "not
> > recommended for production use" ;-)
> >
> 
> I am running both (on at a time of course :) ), now for six month or so,
> ULE is giving me better overall performance, either with or w/o polling. I
> mean network performance. I have net.isr.enable=1 and
> net.inet.ip.fastforwarding=1,
> this way I do get the same network performance I had on the 4.11. I mean I
> have no problem here.
> 
> But also I checked the ULE/BSD against my particular problem and there is
> no difference at all. I get no acceptable disk read performance when
> comparing what I had with 4.11, wether with ULE or with 4BSD

Be very careful, because I've personally measured severe disk I/O
penalties with ULE on SMP hardware.  In fact in my testing ULE gives
worse SMP performance under load across the board compared to 4BSD
(it's only faster for the lightest of workloads).

If you're absolutely certain that ULE is not to blame (and want to
continue to take the risk of other performance and stability problems
down the line), that basically leaves something to do with the scsi
driver and/or its interaction with your hardware as the probable
cause.  I don't know enough about this particular hardware to comment
further though.

Some other comments about your config that are not likely to be
relevant for your I/O problem:

* it's not recommended to use an explicit maxusers value unless you
know that you need it; modern versions of FreeBSD auto-tune with
maxusers 0 which is the recommended configuration.

* adaptive mutexes are usually a win so it's a bit unusual that you
have disabled them, but I assume you have tested this.

* Dunno about the AUTO_EOI_1 option, I don't think you even have this
hardware on your system (device atpic didn't probe in your dmesg).

* HZ=1000 is superfluous since it is the default but may or may not
help.  In some workloads the increased overhead relative to the old
default of HZ=100 gives a performance loss.  Maybe it helps with
polling though, I dunno.

Kris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-performance/attachments/20070113/d1a3dd04/attachment.pgp