Duy Nguyen <pclouds@xxxxxxxxx> writes: > On Wed, Apr 13, 2016 at 1:05 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>>> - access is slow (unless cached, but we can't be sure) >>> >>> We could solve this (and the other problem) with mlock. >> >> Probably you meant madvise(2)? >> >> For something of a size comparable to the index file held by >> index-helper-daemon in-core, I'd expect we wouldn't page too >> badly. > > I had a look at linux implementation of madvise(MADV_WILLNEED). All it > does is force populating the entire memory region, which is good. But > I suspect when memory is under pressure, some pages may be reclaimed. I share that suspicion. Why is such a reclamation bad thing, though? > index files in monster repo case can go up to a few hundred megabytes, > chances of being reclaimed rise accordingly. But we can reconsider > mlock() later when/if real problems happen. Holding onto "a few hundred megabytes" just so that occasional Git operations will not stall with the daemon and slowing down the overall work of the user by panalizing other elements in the user's workflow does not sound like a good trade-off to me. Wouldn't the user better off by not using the daemon at that point, which would give the few hundred megabytes back to the system for better uses? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html