[Fwd: reduce ioremap memory size for Adaptec I2O controllers]

Dave dave at alfar.co.uk
Thu Sep 16 13:04:29 UTC 2004


Alan Cox wrote:

> On Wed, Sep 15, 2004 at 04:13:05AM -1000, Warren Togami wrote:
> 
>>The I2O subsystem currently map all memory from the I2O controller for
>>the controller's in queue, even if it is not necessary. This is a
>>problem, because on some systems the size returned from
>>pci_resource_len() could be 128MB and only 1-4MB is needed.
> 
> 
> Yeah, its an evil hack for the dpt. The only portable way I can see to
> tackle this would be to map 4Mb, init the controller to the point we can
> use its message queue then take every single message to find the highest
> message offset and then send it a lot of NOP messages to return them
> 
> Horrible indeed

Hi Alan

Just to provide everyone with an update of my situation (to show I'm still 
alive and appreciative):

I've tested further, and the I2O subsystem was able to ask ioremap for 128Mb 
without breaking a sweat when booting into a 4g/4g split kernel - VmallocUsed 
turned out to be only 144Mb after boot with gigabytes to spare, so basically 
this turned out to be a non-issue, sorry about that. It does seem wasteful to 
map all of the I2O controllers memory, though.

 From my extremely limited understanding of I2O (I hope I've got this right), 
only some of the shared memory space need be mapped into system memory, with 
the rest available for use by other controllers? Is there any way to query or 
set this range before the messaging layer is established? (seems rather like a 
chicken and egg situation to me)

Presumably it should also be possible to artificially shrink the mapping for 
the message queue by taking all messages and not releasing them if they fall 
outside the preferred range? (even more horrible)

-- 
David Zambonini





More information about the fedora-test-list mailing list