John, Hard to answer your question without knowing a little more information about the state of your system when you are seeing what you are reporting. Also it can vary depending on system hardware and its configuration. Obviously if swapping is needed in order to support some operation you are trying to do and that swap IO is competing with other IO to the same disk resource then you could see delays. I am not sure of RAM utilization on your system when you are seeing what you report to know if this is a candidate. Activating the window may also incur some IO if the application is something like the Finder. So be aware of that as well. It sounds like a resource issue it just very hard to tell what resource: PCI bus, CPU, system RAM, Disk, etc. Anyway, if you can give additional information I could speculate what may be the cause. --- Matthias/John, Regarding what is in Darwin (and Mac OS X)... The Darwin kernel has a unified buffer that both the VM system and file cache utilize. Basically nearly all of system RAM can be used to store file data by the file cache but this data is dropped if the RAM is needed in order to service application RAM needs (any process). If you watch a system in top you can see the number of free pages go down and the number of inactive go up as you pull file data through the system. This is the file cache going to work. I do not believe that any write cashing is done at this point in time. Not because it isn't possible but because the hardware that most run Mac OS X on is not well setup for lazy writing. What if the power goes out, cosmic rays hit your ram, etc. In UPSed environments I could see doing write caching. I do believe that some amount of lazy writing of the file system structures is currently done but not for file system data. Inactive pages can also hold pages related to application executables, libraries and such. Nothing is really dumped out of RAM unless the RAM is needed for something else. This way disk IO can be avoided. Most likely more intelligent reuse algorithms could be added but... In more recent kernels, actually I think the functionality is outside of the kernel, application working set is tracked, analyzed, and recorded. Basically the OS is trying to learn and remember the most likely working sets of applications (which can vary depending on how users work in them) so that the next time the application is launched the most likely pages can be preloaded before a fault is hit. -Shawn On Sunday, January 19, 2003, at 07:40 AM, John Hunter wrote: Hi, I'm sure there are lots of ways to optimise caching, but my question is: why does one process causing a lot of disk access slows down a whole lot other processes which you would think don't require so much disk access (like the Window Manager when you drag a window...). I haven't seen this kind of behaviour with other UNIX systems. John Hello! First of all, I don't know what is implemented in the darwin kernel at all, but here are some of my thoughts about this topic: Preventing disk access for starting applications if nearly impossible, because the data has to be read out for it. It can only be improved by caching all data that was read or reading out sequentially (if possible) data, that will be used. In an offline-situation it is possible to calculate what is the best way to read and cache disk-data, but in the online-situation it is somehow hard to tell which data could be read next. It is easy to guess if someone opens a file, that and begins to read it sequentially, that he could read the whole file, so the system could begin to cache it, if memory is available and no other disk-access is forced. This all shouldn't be a problem which is new to the world, so one should find some online-algorithms with a good competivness in the appropriate text-books. One question would be, how swapping is implemented. There has to be some way of telling the system, that the swap files don't have to be cached. Caching of swap-space is somehow stupid :) By using caches, one could also cache disk-write-access, trying to reduce disk-access at all, enhancing spin-down-times and for mobile users this should reduce battery usage. I was thinking of it some while ago, but hadn't had the time to look at the different parts of darwin related to disk-access. _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored. _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.