On Mon, Feb 15, 2016 at 11:14:13PM -0800, Nag Avadhanam wrote: > On Mon, 15 Feb 2016, Dave Chinner wrote: > > >On Tue, Feb 16, 2016 at 02:58:04AM +0000, Nag Avadhanam (nag) wrote: > >>Its the calculation of the # of bytes of non-reclaimable file system cache > >>pages that has been troubling us. We do not want to count inactive file > >>pages (of programs/binaries) that were once mapped by any process in the > >>system as reclaimable because that might lead to thrashing under memory > >>pressure (we want to alert admins before system starts dropping text > >>pages). > > > >The code presented does not match your requirements. It only counts > >pages that are currently mapped into ptes. hence it will tell you > >that once-used and now unmapped binary pages are reclaimable, and > >drop caches will reclaim them. hence they'll need to be fetched from > >disk again if they are faulted in again after a drop_caches run. > > Will the inactive binary pages be automatically unmapped even if the process > into whose address space they are mapped is still around? I thought they > are left mapped until such time there is memory pressure. Right, page reclaim via memory pressure can unmap mapped pages in order to reclaim them. Drop caches will skip them. > We only care for binary pages (active and inactive) mapped into the > address spaces of live processes. Its okay to aggressively reclaim > inactive > pages once mapped into processes that are no longer around. Ok, if you're only concerned about live processes then drop caches should behave as you want. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
