> Hello,
>
> > PCI latency timer values are only usefull when several devices are
> > requesting the PCI bus at the same time, by allowing BUS acquisition
> > latency prediction for the whole system. Setting a large value for a
> > device latency timer in low level drivers is kind of ego-mania and is
> > highly wrong and broken.
>
> The problem is that many BIOSes set the latency timer to horribly low
> values, causing poor performance.
As David did, you removed the offending code in your response. Must I
deduce that somebody is ashamed of it. ;-)
The code said:
- > 10 is reasonnable
- <= 9 is not and shall be changed to 255.
If PCI gurus are ok about a 30 micro-second PCI latency being good for a
system, and claim that this code actually fixes-up something, then I have
nothing more to add to this thread.
> > You may want/need to fix at driver level some PCI BIOS and/or PCI driver
> > quirks. If you need to do so, it is advisable to apply reasonnable fix-up
> > and to have these fix-ups optionnal if possible.
> >
> > In the perfect PCI world, system PCI softwares have enough informations to
> > configure resources for all PCI devices. In order to assign good values
> > for latency timers, system PCI softwares should take into account the real
> > load of the system. Since neither PCI BIOSes, nor kernel PCI driver does
> > accept any parameters about some probable system load in order to assign
> > good pci timer value to PCI devices, actual PCI BUS latency is probably
> > often bad tuned for heavily loaded systems.
> > For such systems, a driver that sets the PCI latency timer of a device to
> > 255 has every chance to make things worse.
>
> Actually I've tried to move all latency timer magic to generic PCI code, but
> DaveM found that several devices get confused for some values of CFLT (one
> example is the Sun HME Ethernet), so I removed it and introduced the
> pci_set_master function. All drivers for sane devices should call this function
> which will be eventually extended to handle CFLT setting in a better way.
>
> > Imagine a system with 4 devices using a PCI latency timer of 255 and being
> > able to burst as long as this time.
> > The predicable PCI BUS latency for any other PCI device is at least:
> > 0.030 x 4 x 255 = 30.6 micro-seconds.
> > 1020 PCI cycles.
> > 4080 bytes for 32bit PCI.
> > 8160 bytes for 64bit PCI.
> In such cases, it's best to use setpci in your startup scripts to set
> the values you want. The kernel cannot know whether you want maximum
> bandwidth or minimum latency.
_I_, you, David, ..., can do that and even can fix the source for their
personnal use.
What about most of the 7.5 millions linux users?
The kernel must use reasonnable default value and _small_ value are a lot
more reasonnable than _large_ value for PCI latency timers. This lets me
tell you that I consider the current Linux PCI latency timer brain-damage
that forces so _large_ values to be far more _broken_ than the PCI BIOSes
default settings they are claiming to fix up.
Regards,
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/