On 1/13/02 at 2:26 PM Marcel Kilgus wrote: >Thierry Godefroy wrote: >> Another way to use them wisely, is to limit the amount of total caching >> memory they can use (thus also limiting the amount of time needed to >> search among all existing slave blocks for your data...). IIRC Marcel >> uses this trick to speed things up under QPC.
>I tried (by exploiting the Atari kernel whose "fast memory" support >already prohibits slave blocks in fast memory), but couldn't get it to >work. Not much joy in debugging there, so I trashed it. Marcel, if I recall correctly, the size of the slave block table and therefore the number of slave blocks is established at SMSQDOS init time after the amount of free RAM is determined. Unfortunately, the neurons that held information on how the actual SBT search is performed (what establishes the end of the table) have been reused :-), but wouldn't it be possible to manipulate the maximum number of slave blocks by manipulating the apparent max RAM found when the table is first created? I know that with the way the table works, limiting it's size also limits the position of the block of RAM that can be used as slave blocks. IIRC, they would be restricted to low adresses, which would then co-incide with the bottom of the common heap, so many allocations there would eventually completely prevent slaving, and IIRC this is a very undesirable condition because some drivers cannot cope. But maybe the common heap start could be moved up. If nothing else by making a false allocation and then linking over it's entry so that it's not seen any more and cannot be considered for de-allocating, but then changes in the slave block table would declare this 'free' and available for slaving. This could also be done at init time, making the trick invisible to anything that happens after that. The bottom of the common heap and the top of the chosen slave block area size could also overlap somewhat, which in effect would mean that there would be a guaranteed minimum of slave blocks available that would never be turned into anything else by resource allocation. With memory sizes what they are today, we could also just dedicate an amount of memory for slaving only, no need for any overlaps. Overlaps would only happen if the actual RAM was smaller or equal to the maximum slave block limit chosen. This would make it much simpler to try out stuff in environments with a lot of RAM (a lot in SMSQDOS terms). I guess that way on QPC with enough RAM in the PC, we could finally see if programs can cope with 512M :-) (shich seems to be the maximum...) Nasta
