Re: [PATCH] inotify to minimize stat() calls

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Apr 24, 2013 at 4:32 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote:
> On Thu, Apr 25, 2013 at 3:20 AM, Robert Zeh <robert.allan.zeh@xxxxxxxxx> wrote:
>> Here is a patch that creates a daemon that tracks file
>> state with inotify, writes it out to a file upon request,
>> and changes most of the calls to stat to use said cache.
>>
>> It has bugs, but I figured it would be smarter to see
>> if the approach was acceptable at all before spending the
>> time to root the bugs out.
>
> Any preliminary performance numbers? How does it do compared to
> no-inotify version? When only a few files are changed? When half the
> repo is changed?

No numbers yet; I'm still working on correctness.  What I posted does
not pass all of the tests.

I like your ideas for performance tests.  My testing setup is
a VirtualBox instance on MacOS, so I'm not convinced that my numbers
will be meaningful.  The one thing I can report is that running the daemon
doesn't affect compilation performance.

The real win for this type of cache is Windows, where the file system
is slow.

>> I've implemented the communication with a file, and not a socket, because I
>> think implementing a socket is going to create
>> security issues on multiuser systems.  For example, would a
>> socket allow stat information to cross user boundaries?
>
> I think UNIX socket on Linux at least respects file permissions. But
> unix(7) follows with "This behavior differs from many BSD-derived
> systems which ignore permissions for Unix sockets". Sighh
>
>>  abspath.c            |   9 ++-
>>  bisect.c             |   3 +-
>>  check-racy.c         |   2 +-
>>  combine-diff.c       |   3 +-
>>  command-list.txt     |   1 +
>>  config.c             |   3 +-
>>  copy.c               |   3 +-
>>  diff-lib.c           |   3 +-
>>  diff-no-index.c      |   3 +-
>>  diff.c               |   9 ++-
>>  diffcore-order.c     |   3 +-
>>  dir.c                |   4 +-
>>  filechange-cache.c   | 203
>> +++++++++++++++++++++++++++++++++++++++++++++++++++
>>  filechange-cache.h   |  20 +++++
>>  filechange-daemon.c  | 164 +++++++++++++++++++++++++++++++++++++++++
>>  filechange-printer.c |  13 ++++
>>  git.c                |  27 +++++++
>>  ll-merge.c           |   3 +-
>>  merge-recursive.c    |   5 +-
>>  name-hash.c          |   3 +-
>>  name-hash.h          |   1 +
>>  notes-merge.c        |   3 +-
>>  path.c               |   5 +-
>>  read-cache.c         |  11 +--
>>  rerere.c             |   7 +-
>>  setup.c              |   5 +-
>>  test-chmtime.c       |   2 +-
>>  test-wildmatch.c     |   2 +-
>>  unpack-trees.c       |   6 +-
>>  29 files changed, 486 insertions(+), 40 deletions(-)
>>  create mode 100644 filechange-cache.c
>>  create mode 100644 filechange-cache.h
>>  create mode 100644 filechange-daemon.c
>>  create mode 100644 filechange-printer.c
>>  create mode 100644 name-hash.h
>
> Can you just replace lstat/stat with cached_lstat/stat inside
> git-compat-util.h and not touch all files at once? I think you may
> need to deal with paths outside working directory. But because you're
> using lookup table, that should be no problem.

That's a good idea; but there are a few places where you want to call
the uncached stat because calling the cache leads to recursion or
you bump into things that haven't been setup yet.  Any ideas how to
handle that?
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]