Re: [Fwd: [patch #2508] ext2fs support for large store (> 1.5G)]

[Marco Gerards]

Ognyan Kulev <ogi@fmi.uni-sofia.bg> 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