Andreas Beck wrote:
>
> The problem with both functions is, that their required runtime is of the
> order of the total file size, not the change file size.
Hmm, there was a patch on l-k about this: Insted of scanning the entire
cache to see if any relevant pages needs flushing, all dirty pages was
put on a linked list to facilitate faster fsync and friends. Don't know
what happened to it.
One should think that a "solution" would be to squeeze the cache to a
fixed (small) ammount of memory, to speed up the cache-walk. This will
not work if the algorithms/data-structures actually walks the entire
tree of inderection blocks... I surely hope it doesn't do *that* ?
If so, running a large (real) database on filesystem devices would be.... slow.
> This causes my framerate to drop from full 25fps down to 4 fps after about
> 600 frames. ARGL.
The linear searches should explain this behaviour, but I'd think this
would only happen on the first run to prime and size the cache, and be
dead slow all the way on the second run? Unless of course, you are
right and the kernel do in fact walk *all* inderection blocks and do a
cache lookup too see there are dirty pages... In addition to the time
it takes to walk and hash, it fills the cache with useless inderection
blocks.... sick. Someone tell me it is not so?
Regards,
Morten Rolland
