"Neal H. Walfield" <[EMAIL PROTECTED]> writes: > I am interested in the following detail of your plan: when do you > drain the cache? When it is full? If we set the cache size to 2GB > then you have a lot of mappings to manage. The hashes that I have are > proportional to the size of the kernel cache.
I can size the cache to be whatever is a good amount. However much memory you want to devote to the task is fine. It's all pageable store, so it's not a critical issue in detail, I think. The cache isn't drained; it's generally kept full. When you need a mapping, you free an old one (by LRU or random replacement) and allocate a new one. There are really two separate parts, I suspect: First, a table that correlates disk blocks (or disk features like inodes) with mappings--an association table--this is a table that you have as well, of course. But I can store this in lots of easy ways: for example, I can store it in the existing dinode structures perhaps. Not sure the best place. Second, a record of extant mappings, which must include some kind of reference count (which you have as well) and which is easy to free. You just call "vm_free" and the section is deleted. There is no attempt or need to re-use the same mapping location. So you decide "this is how many mappings to keep", where the amount is determined by the amount of virtual memory you have and how much you want to spend on bookkeeping data. The best way to tune that is probably to do some instrumentation. At some point, keeping more mappings is pointless because they don't get used much. In the steady state, you always free a mapping whenever you create a new one. Thomas _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-hurd
