Problems with lock-object/lock-completed in libpager

[Sergio Lopez]

Hi,

I've found two problems with the current use of
lock_object/lock_completed in libpager:

  - When a translator wants to synchroize all the contents of a pager,
    it must call to pager_sync(), which in turn calls to
    m_o_lock_object for the entire length of the object, and waits for
    lock_completed if sync==1. This way, we are asking the kernel to
    return us all dirty pages of that object by using m_o_data_return.
    When syncing a large object, it generates a lot of requests in a
    short amount of time, so a lot of threads are created to deal with
    them.

    Spliting the lock request in multiple calls for large objects
    helps a bit by giving the pager the chance to deal with some
    requests between calls (specially when using a queue, as I
    commented in a previous mail), but it is not a proper solution.


  - sync() doesn't really waits for the contents to be written to disk.
    Receiving a m_o_lock_completed from the kernel, only means that it
    has dispatched the data to a translator, but this one still needs
    to write them to the storage. This could be related to bug #29292.


For solving these issues, I think pagers should be able to know which
pages are currently dirty (implementing a new RPC?) before calling to
m_o_lock_object. This way, they could wait for the pages to be returned
by the kernel, assuring they are properly written before returning from
sync(). They could also (indirectly) throttle the number of threads to
be created, by knowking how many m_o_data_return requests are going to
be received for each m_o_lock_object call.

Other ideas?