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

Re: [PATCH v2 0/2] fsmonitor inline / testing cleanup

From
Nipunn Koorapati <nipunn1313@gmail.com>
Date
Oct 22, 2020, 20:59 UTC
Message-ID
<CAN8Z4-Vb3qc7eyzczEC7hcf3DmHEXkcV1AGRfC_L0uFKDU2W5A@mail.gmail.com>
In-Reply-To
<xmqq7drim5st.fsf@gitster.c.googlers.com>
> from Taylor
> I'm still iffy on whether or not this series makes sense to apply
> without the rest of the code that depends on it
Sorry for confusion. I don't think we should assume there is more code coming
related to this. I think this is intended to stand on its own.
It's not a required dependency either. Rather, it's motivated by
simplicity
- remove the dir.h dependency from fsmonitor.h.
- Keep implementation in fsmonitor.c and definitions in fsmonitor.h
> From Junio
> Those without fsmonitor would pay the call/return cost for no good
> reason if core_fsmonitor is not set, and checking that on the caller
> side may make a big difference.  How big?  That needs measurement.

Noted! This is not called out or measured - it is simply assumed based on earlier conversation. I should be able to run the fsmonitor perf suite before/after this change and include the results in the commit message.

Show 8 quoted lines
> This is a tangent, but with or without inlining, I find it iffy to
> see that untracked_cache_invalidate_path() is called only when
> fsmonitor is in use.  Does untracked_cache depend on fsmonitor for
> its correct operation?  Why is it OK not to invlidate when the
> caller would tell fsmonitor that a path is invalid if fsmonitor were
> in use?  The call is a statement of fact that the path is no longer
> valid, and that bit of information would be useful to the parts of
> the system outside fsmonitor, no?  Puzzled....

I did some source diving in an attempt to understand what's happening here. I believe that untracked_cache_invalidate_path() is called in dir.c whenever an entry is added or removed from a directory. This is an additional call when fsmonitor is enabled - because fsmonitor's whole purpose is to avoid the lstat on the other path. There is a nice explanation in the original commit message

Commit 883e248b (fsmonitor: teach git to optionally utilize a file system monitor to speed up detecting new or changed files., 2017-09-22)

--Nipunn
Previous: Junio C Hamano
Message 18 of 18 in “fsmonitor inline / testing cleanup”
  1. 0/2 fsmonitor inline / testing cleanupNipunn Koorapati via GitGitGadget, Oct 21, 2020
  2. 2/2 fsmonitor: make output of test-dump-fsmonitor more conciseAlex Vandiver via GitGitGadget, Oct 21, 2020
  3. 1/2 fsmonitor: stop inline'ing mark_fsmonitor_valid / _invalidAlex Vandiver via GitGitGadget, Oct 21, 2020
  4. Taylor BlauOct 21, 2020
  5. Junio C HamanoOct 21, 2020
  6. Taylor BlauOct 21, 2020
  7. Junio C HamanoOct 21, 2020
  8. Nipunn KoorapatiOct 21, 2020
  9. Taylor BlauOct 21, 2020
  10. Nipunn KoorapatiOct 21, 2020
  11. 0/2 fsmonitor inline / testing cleanupNipunn Koorapati via GitGitGadget, Oct 22, 2020
  12. 2/2 fsmonitor: make output of test-dump-fsmonitor more conciseAlex Vandiver via GitGitGadget, Oct 22, 2020
  13. 1/2 fsmonitor: stop inline'ing mark_fsmonitor_valid / _invalidAlex Vandiver via GitGitGadget, Oct 22, 2020
  14. Taylor BlauOct 22, 2020
  15. Junio C HamanoOct 22, 2020
  16. Taylor BlauOct 22, 2020
  17. Junio C HamanoOct 22, 2020
  18. Nipunn KoorapatiOct 22, 2020

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.