Hi Michael,
Cache pollution is not an issue when your cache is already tiny - it's always being flooded. The BUFFERS cache primary exists to pick up the easy case of sectors being read or modified close in time, like during a FAT update...
Even then, it is much better to only invalidate the buffers cache when int2526 and int21.7305 access happens - which is what the kernel is trying to do now, only with the simple bug that it is only doing it depending on whether the access fails or succeeds. It is worse if int25 etc. access is "redirected" through the cache: While int25 etc. would normally let you read or write many sectors in a single call, which is implemented using AS FEW AS POSSIBLE int13 calls in the kernel, BUFFERS always are individual 512 byte sectors. Exactly because BUFFERS are meant to only cache those small things like FAT or directory data access they are not suited to be fully put into the loop for int25 etc. access which can be large blocks. Again, I propose to let int25 etc. handling ONLY check and sync content which ALREADY is in the buffers but NOT allow it to put NEW sectors in the buffers cache.
Look at it like this .. loading almost any program is going to wipe out the buffers cache. We're not protecting anything by keeping INT 25/26 traffic out of it.
See above. We now invalidate the buffers and we now invalidate ONLY the buffers for the affected drive. This already is the maximum impact on the cache which we should reasonably allow. To get back to the original *bug of int25 int26 and int21.7305 doom* The following should not CONDITIONALLY but ALWAYS call setinvld: https://github.com/FDOS/kernel/blob/032523a2bb14133d51f17dda0bef55208d12e1a0/kernel/inthndlr.c#L405 https://github.com/FDOS/kernel/blob/032523a2bb14133d51f17dda0bef55208d12e1a0/kernel/inthndlr.c#L1868 As you see, int2526_handler ONLY calls setinvld on I/O error, while int21_fat32 ONLY calls setinvld on I/O success. BOTH should ALWAYS call setinvld - both for success and failure. They should do this at least for writes, but even better also for reads, unless you know for sure that no dirty buffers can exist during int25, int26 or int21.7305 calls. In most cases, the kernel writes back dirty buffers as soon as possible. You can see that functions like dir_write_update use buffers to do their work, but end with a flush_buffers call, so the dirty buffers should ONLY exist during int21 call handling, but I have not checked whether ALL functions work like that. Either way, I recommend to NOT use getblk or searchblock when checking whether a given sector is in BUFFERS, because those have the here unwanted side-effect of ADDING the investigated sector to the BUFFERS cache rather than only SEARCHING for it. Regards, Eric _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
