Ognyan Kulev <[EMAIL PROTECTED]> writes: >> When there are no pages free you just throw the entire cache away (if >> I understand it correctly). I do not like this because this can be >> one of the main factors that will slow down someone's computer. Isn't >> it possible to ask Mach to evict 10 pages (for example)? Mach usually >> knows better which pages should be evicted. If that is not possible >> you can just evict 10 pages (10 was randomly chosen) and evict the >> non-dirty pages first. > > In the text, there is some rationale behind flushing all pages with > reference count zero. Dirty pages are not flushed, because they have > refcount > 0. (Dirty pages are always in some pokel or are synced > before deref.)
Right, I forgot about the pokels. But I missed the rationale behind flushing _all_ the pages with ref. count zero. I understand why it has to be zero, I just do not understand why you have to flush all instead of just a few. Perhaps I just read over the text, can you please point me to it? >> There is some possible locking problem: >> The call disk_cache_wait_remapping is called with disk_cache_lock >> locked. The condition in disk_pager_read_page is broadcasted while >> disk_cache_lock is locked too. > > This is by design. condition_wait unlocks the lock and waits. When > condition is broadcasted, it locks the lock again, potentially > blocking the thread. In our case, this will make > disk_cache_wait_remapping to wait until disk_pager_read_page unlocks > disk_cache_lock. Right, I forgot about condition_wait doing this. >> Have you fixed the bug I reported BTW? > > No, unfortunately I still haven't found time for debugging :-( But > this is something that must be fixed before RC2. Ok. -- Marco _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
