On Mon, Dec 22, 2014 at 14:59, Mike Belopuhov wrote: > 1) how is it different from what we have now? > > 2) why can't you do it when you pool_put?
Right now, if you allocate a bunch of things, then free them, the pages won't be freed because the timestamp is new. But you've already freed everything, so there won't be a future pool_put to trigger the final page freeing. This keeps pages from getting stuck. > 3) why can't you call it from uvm when there's memory pressure since > from what i understand pool_reclaim was supposed to work like that? Calling reclaim only when we're low on memory is sometimes too late. > 4) i assume you don't want to call pool_reclaim from pool_gc_pages > because of the mutex_enter_try benefits, but why does logic in > these functions differ, e.g. why did you omit the pr_itemsperpage > bit? We're not trying to release all free pages. Only the ones that are both too many and too old. This is the same logic that is already in pool_put. > 7) it looks like pool_reclaim_all should also raise an IPL since it > does the same thing. wasn't it noteced before? Likely. I don't think reclaim_all gets called very often.
