He indicated that he would threaten to include reiser4 in 2.6.19 once we
got our fixes back to him (as a way of getting more comments), and that
it would most likely go in in 2.6.20 as a result.  I told him that most
of the team was on vacation or sick, so we would probably be delayed in
getting the fixes back to him.  If by chance more of the work is done
than I fear, it would be nice to get it to him soon...

We discussed dentry cache, and the framgentation problems it has (where
one dentry being active keeps a whole page around).  He suggested that
by using the reclaim code and ignoring the cases where dentries are
referenced, they could be repacked without too much coding.  I think we
both think repacking is the right answer, as dcache is very inefficient
in its pruning without it.

We discussed the library vs. control thread owning issues for the
generic code.   I think he agrees in principle, but I sense he would
want to see a good generic code library approach implemented before he
would accept it, which is rather reasonable.  He prefers fixing generic
code to needlessly duplicating it. 

He said that inodes and dentries don't saw tooth in their usage.  I had
remembered the code as letting them increase to more and more percentage
of RAM until their is a crisis shortage of memory, at which point the
shrink_* code for them gets finally invoked.  He assured me I was
incorrect, I guess I need to go reread that code.

All in all, he is a very perceptive and reasonable fellow who knows what
he is doing.

hans

Reply via email to