On Wed, Sep 04, 2019 at 09:27:00AM +0300, Andriy Gapon wrote: > On 04/09/2019 01:01, Mark Johnston wrote: > > Some of the vm_lowmem eventhandlers probably shouldn't be called each > > time the page daemon scans the inactive queue (every 0.1s under memory > > pressure). ufsdirhash_lowmem and mb_reclaim in particular don't seem > > like they need to be invoked very frequently. We could easily define > > multiple eventhandlers to differentiate between these cases, though. > > My proposal is to run uma_reclaim(UMA_RECLAIM_TRIM) before invoking vm_lowmem. > If that reclaims "enough" memory, then do not call vm_lowmem at all. > > Oh, and I have a related question. > Say, a zone has X items in use and Y items in cache. > After running vm_lowmem the composition changes to X - C and Y + C > respectively. > Then we run uma_reclaim(UMA_RECLAIM_TRIM). > Question: is that guaranteed to free at least C items?
No. The estimation cannot distinguish between items that were freed as a result of a lowmem request vs. those that were freed as a regular operation. As a result it considers the extra C items as part of the cache's working size. > I am thinking about a possibility that the zone's workset size is estimated to > be at least X (and maybe even more than X + Y). In that case UMA_RECLAIM_TRIM > won't free those C items, they will stay in the cache. So, it seems like > releasing them was in vain, at least for the immediate reclaim. This is true. Of course, the items may eventually become reclaimable as the estimate decays. _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
