At 11:28 PM 5/5/2005 +0400, Arkady V.Belousov wrote:
I think, EMM386 should allocate not 32M for EMS+UMB, but 32M for EMS and different memory for UMB (as previously).
No, it didn't do that previously. It just looked like it did. In fact, it ate one extra EMS handle that it doesn't currently since UMB's are assigned to the system handle in 2.x.
- open/close pages (especially open) now noticeably slower.
The open and close MFT benchmark is bogus for real world applications except to detect pathological conditions where a function is taking an inordinate amount of time to complete. No useful application needs to allocate all its memory, then free it all, over and over again in a timespan of milli- or microseconds per cycle. Doing that stresses the EMM386 allocator since, if and only if, you free all pool block memory associated with an XMS block, the memory manager releases the XMS block.
Releasing memory back to XMS inevitably has a large overhead. Allocating a new block from XMS has sizeable overhead as well, but not as much as freeing back since freeing requires all internal pool blocks be walked twice to test if empty and then marked free. Further, the more memory you have, the more the overhead for CPU-tight cycles of pure all allocate/all free grows as a linear function.
Last line with extended memory amounts is overflowing for both MS and FD. For example, MS extended total is less than largest block. The numbers aren't meaningful unless you want to back-compute the overflow points.
------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
