Could we change the searches for PCI ROMs so that we look through CBFS and then for each ROM we find in CBFS we find the device instead of vice versa? It seems like we wouldn't lose a lot of generality, but we'd lose a lot of spew in the logs.
Any objections?
Thanks, Myles
Myles Watson wrote:
Could we change the searches for PCI ROMs so that we look through CBFS and then for each ROM we find in CBFS we find the device instead of vice versa? It seems like we wouldn't lose a lot of generality, but we'd lose a lot of spew in the logs.
Is this coreboot or SeaBIOS?
What about we stop the spew rather than changing the algorithm?
On Fri, Sep 25, 2009 at 10:00 AM, Stefan Reinauer stepan@coresystems.de wrote:
Myles Watson wrote:
Could we change the searches for PCI ROMs so that we look through CBFS and then for each ROM we find in CBFS we find the device instead of vice versa? It seems like we wouldn't lose a lot of generality, but we'd lose a lot of spew in the logs.
Is this coreboot or SeaBIOS?
Both.
What about we stop the spew rather than changing the algorithm?
I think both need to be done. On a mainboard with many devices it seems silly to keep looking through the same two CBFS entries for ROMs. Is there a reason to do it that way that I'm missing?
Myles
On Fri, Sep 25, 2009 at 9:26 AM, Myles Watson mylesgw@gmail.com wrote:
Is there a reason to do it that way that I'm missing?
I think what you're saying makes a lot of sense. It was hard to do before CBFS, but it's very easy to do now. I think we should do it.
ron
Myles Watson wrote:
What about we stop the spew rather than changing the algorithm?
I think both need to be done. On a mainboard with many devices it seems silly to keep looking through the same two CBFS entries for ROMs. Is there a reason to do it that way that I'm missing?
Well, it's quite against the device centric model we have at the moment... That made me hesitate.
But your reasons are very sound. It's quite a lot of cbfs accesses, and generally I guess walking the device tree (in coreboot it's even a memory op, and not a pci config space op) is cheaper than walking all of the rom all of the time...
Stefan
On Fri, Sep 25, 2009 at 11:57 AM, Stefan Reinauer stepan@coresystems.dewrote:
Myles Watson wrote:
What about we stop the spew rather than changing the algorithm?
I think both need to be done. On a mainboard with many devices it seems silly to keep looking through the same two CBFS entries for ROMs. Is there a reason to do it that way that I'm missing?
Well, it's quite against the device centric model we have at the moment... That made me hesitate.
That's a valid point. Now I wonder how it could be implemented so that we get the precedence of CBFS then ROM if it exists correct, so that only one gets executed.
But your reasons are very sound. It's quite a lot of cbfs accesses, and generally I guess walking the device tree (in coreboot it's even a memory op, and not a pci config space op) is cheaper than walking all of the rom all of the time..
It's not a show-stopper for me, but I thought I'd bring it up when I came to it.
Thanks, Myles
On 25.09.2009 20:04, Myles Watson wrote:
On Fri, Sep 25, 2009 at 11:57 AM, Stefan Reinauer stepan@coresystems.dewrote:
But your reasons are very sound. It's quite a lot of cbfs accesses, and generally I guess walking the device tree (in coreboot it's even a memory op, and not a pci config space op) is cheaper than walking all of the rom all of the time..
It's not a show-stopper for me, but I thought I'd bring it up when I came to it.
Given that ages ago my proposal to add caching for LAR entries was rejected (and I don't think positions have changed since then), LAR/CBFS walking will stay somewhat expensive. You could build a special-case cache of LAR entries for PCI option ROMs and hope nobody remembers the original rejections. It would definitely speed up things a lot, while saving you the trouble of changing the current option ROM init model.
Regards, Carl-Daniel
On Fri, Sep 25, 2009 at 5:41 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Given that ages ago my proposal to add caching for LAR entries was rejected (and I don't think positions have changed since then), LAR/CBFS walking will stay somewhat expensive.
We have about 4 entries in the typical CBFS. I just don't see how the price of walking it can be a major item. It used to be until I created the "giant empty space" file. Now, walking a whole LAR can be done in short order. I'm happy to time it but I bet uncached it's still far less than one millisecond.
We should always cache ROM and, if we are not, then, we should.
I guess I am not sure this is a huge problem.
ron
On 26.09.2009 07:16, ron minnich wrote:
On Fri, Sep 25, 2009 at 5:41 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Given that ages ago my proposal to add caching for LAR entries was rejected (and I don't think positions have changed since then), LAR/CBFS walking will stay somewhat expensive.
We have about 4 entries in the typical CBFS. I just don't see how the price of walking it can be a major item. It used to be until I created the "giant empty space" file. Now, walking a whole LAR can be done in short order. I'm happy to time it but I bet uncached it's still far less than one millisecond.
We should always cache ROM and, if we are not, then, we should.
I guess I am not sure this is a huge problem.
It is apparently enough of a problem to be noticed by Myles.
Myles, do you have any timing measurements we could use to assess the impact for the non-verbose case? I know that serial printing slows everything down to a crawl, but if the CBFS code emits no messages at all, how long does it take to walk the entire ROM (unsuccessful walk)?
Regards, Carl-Daniel
On Sat, Sep 26, 2009 at 2:24 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
It is apparently enough of a problem to be noticed by Myles.
no. The original note is about spew, not about performance of cbfs.
ron
On 26.09.2009 18:27, ron minnich wrote:
On Sat, Sep 26, 2009 at 2:24 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
It is apparently enough of a problem to be noticed by Myles.
no. The original note is about spew, not about performance of cbfs.
Sorry, I missed that. As long as loads of debug output are there if I select SPEW, I have no problems with people lowering the levels of debug messages. I use SPEW anyway to track behavioural changes from revision to revision.
Regards, Carl-Daniel
On Sep 26, 2009, at 2:41, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net
wrote:
On 25.09.2009 20:04, Myles Watson wrote:
On Fri, Sep 25, 2009 at 11:57 AM, Stefan Reinauer <stepan@coresystems.de
wrote:
But your reasons are very sound. It's quite a lot of cbfs accesses, and generally I guess walking the device tree (in coreboot it's even a memory op, and not a pci config space op) is cheaper than walking all of the rom all of the time..
It's not a show-stopper for me, but I thought I'd bring it up when I came to it.
Given that ages ago my proposal to add caching for LAR entries was rejected (and I don't think positions have changed since then), LAR/ CBFS walking will stay somewhat expensive. You could build a special-case cache of LAR entries for PCI option ROMs and hope nobody remembers the original rejections. It would definitely speed up things a lot, while saving you the trouble of changing the current option ROM init model.
I don't think we do have a problem just yet... Let's not add another layer of complexity to fight the one that *might* be there... For now the biggest waste of time is just extensive while uninformative because repetetive serial output.
Stefan
Regards, Carl-Daniel
On Fri, Sep 25, 2009 at 09:30:42AM -0600, Myles Watson wrote:
Could we change the searches for PCI ROMs so that we look through CBFS and then for each ROM we find in CBFS we find the device instead of vice versa?
SeaBIOS needs to run roms located on external PCI cards, so it can't just walk the list of CBFS roms.
It seems like we wouldn't lose a lot of generality, but we'd lose a lot of spew in the logs.
I'd just lower the debug level to reduce the log spew.
If you're concerned about performance, then I suggest running some tests. On my machine the time to walk the CBFS was negligible. In SeaBIOS, there is tools/readserial.py which can show the timing for log messages. I use:
tools/readserial.py /dev/ttyUSB0 115200
This tool will read the serial port, and show each message with a time delta - it will subtract out the cost of the serial port write when showing the timing. (It will also keep a log - for example: seriallog-20090916_220220.log) How about running it and forwarding the results for your machine?
Ultimately, I think it would probably be simpler to cache the list of files in CBFS then it would be to rework the option rom scanning. However, it would be even simpler to just enable caching of the rom. This is something I'd like to see coreboot do anyway - not because of the cost of cbfs walking, but because lzma decompression is really slow due to lack of caching.
-Kevin
-
Carl-Daniel Hailfinger -
Kevin O'Connor -
Myles Watson -
ron minnich -
Stefan Reinauer