Hi Eric, > thank you for the analysis that int 25/26 disk access > (and int 21.73 access) bypass the kernel BUFFERS cache.
> Note that int21_fat32 (int 21.7305) would even get > disk area type flags (dir, fat, data) from the caller, > which would make it easier to "buffer" those calls. > I agree that you would get better performance when > raw writes just UPDATE buffer contents instead of > triggering full cache INVALIDATION. full cache INVALIDATION is only needed because the BUFFERS cache might have stale data that are not yet on disk. It's a brute force clutch, not a real solution. The solution should be to use the same BUFFERS cache for both internal mk_dir etc. operations, and external lfn_mkdir operations. > I suggest that raw writes should not FILL buffers, > but only UPDATE buffers for those sectors which > already happen to be in the buffers. This happens automagically in the current context as DOSLFN newer writes sector data, but always read/modify/writes data. So data written to are already in the cache, read microseconds before. i.e. treat external int2526_handler reads/writes like internal mk_dir reads/writes, while observing the int21_fat32 (dir, fat, data) destination. basically cache dir and fat calls, don't cache data or unknown. > Thoughts about write-combining: leave write_combining for another day. currently this is about bug fixing, not performance enhancing. Leave SMARTDRV like performance for another day; FreeDOS managed without it for the last 30 years. It's mind blowing better then not-delayed-write caching for certain use cases like compiling large packages repeatedly, but mostly pointless in todays SSD based virtual environments. Nice to have, but mostly pointless in 2025. Tom _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
