git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v3 03/16] index-helper: new daemon for caching index and related stuff

From
David Turner <dturner@twopensource.com>
Date
Apr 14, 2016, 18:20 UTC
Message-ID
<1460658054.5540.89.camel@twopensource.com>
In-Reply-To
<xmqqd1psgiuc.fsf@gitster.mtv.corp.google.com>
On Thu, 2016-04-14 at 11:12 -0700, Junio C Hamano wrote:
Show 34 quoted lines
> Duy Nguyen <pclouds@gmail.com> writes:
> 
> > On Wed, Apr 13, 2016 at 1:05 AM, Junio C Hamano <gitster@pobox.com>
> > 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?

By running git index-helper, the user has signaled their intent about memory usage. It's probably reasonable to honor this intent (even if the user might be mistaken about what the right trade-off is).

Previous: Junio C HamanoNext: Duy Nguyen
Message 18 of 37 in “index-helper, watchman”
  1. 00/16 index-helper, watchmanDavid Turner, Apr 6, 2016
  2. 01/16 read-cache.c: fix constness of verify_hdr()David Turner, Apr 6, 2016
  3. 02/16 read-cache: allow to keep mmap'd memory after readingDavid Turner, Apr 6, 2016
  4. 03/16 index-helper: new daemon for caching index and related stuffDavid Turner, Apr 6, 2016
  5. Johannes SixtApr 7, 2016
  6. Johannes SchindelinApr 7, 2016
  7. David TurnerApr 7, 2016
  8. Johannes SchindelinApr 8, 2016
  9. Duy NguyenApr 8, 2016
  10. David TurnerApr 8, 2016
  11. David TurnerApr 11, 2016
  12. Duy NguyenApr 12, 2016
  13. David TurnerApr 12, 2016
  14. Junio C HamanoApr 12, 2016
  15. David TurnerApr 13, 2016
  16. Duy NguyenApr 14, 2016
  17. Junio C HamanoApr 14, 2016
  18. David TurnerApr 14, 2016
  19. Duy NguyenApr 15, 2016
  20. Junio C HamanoApr 15, 2016
  21. 04/16 index-helper: add --strictDavid Turner, Apr 6, 2016
  22. 05/16 daemonize(): set a flag before exiting the main processDavid Turner, Apr 6, 2016
  23. 06/16 index-helper: add --detachDavid Turner, Apr 6, 2016
  24. 07/16 read-cache: add watchman 'WAMA' extensionDavid Turner, Apr 6, 2016
  25. 08/16 Add watchman support to reduce index refresh costDavid Turner, Apr 6, 2016
  26. 09/16 index-helper: use watchman to avoid refreshing index with lstat()David Turner, Apr 6, 2016
  27. Junio C HamanoApr 7, 2016
  28. Junio C HamanoApr 7, 2016
  29. David TurnerApr 8, 2016
  30. Junio C HamanoApr 8, 2016
  31. 10/16 update-index: enable/disable watchman supportDavid Turner, Apr 6, 2016
  32. 11/16 unpack-trees: preserve index extensionsDavid Turner, Apr 6, 2016
  33. 12/16 index-helper: kill modeDavid Turner, Apr 6, 2016
  34. 13/16 index-helper: don't run if already runningDavid Turner, Apr 6, 2016
  35. 14/16 index-helper: autorun modeDavid Turner, Apr 6, 2016
  36. 15/16 index-helper: optionally automatically runDavid Turner, Apr 6, 2016
  37. 16/16 read-cache: config for waiting for index-helperDavid Turner, Apr 6, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.