Re: [RFC][PATCH] inotify 0.10.0

From: Paul Jackson (pj_at_sgi.com)
Date: 09/30/04

  • Next message: Alan Cox: "PATCH: Kconfig for EDD"
    Date:	Thu, 30 Sep 2004 10:48:08 -0700
    To: Ray Lee <ray-lk@madrabbit.org>
    
    

    Ray wrote:
    > However, dnotify has shown that forcing userspace to cache the
    > entire contents of all the directories it wishes to watch doesn't scale
    > well.

    The dnotify cache isn't just an optional performance tweak, caching
    inode to name. It's an essential tracking of much of the stat
    information of any file of interest, in order to have _any_ way of
    detecting which file changed.

    The inotify cache could just have the last few most recently used
    entries or some such - it's just a space vs time performance tradeoff.

    So passing back an inode number doesn't come close to reintroducing
    the forced tracking of all the interesting stat data of every file.

    > dnotify already forces an O(N) workload per directory onto
    > userspace, and that has shown itself to not work well.

    Just because there exists an O(N) solution that has been shown to fail
    doesn't mean all O(N) solutions fail. If the constants change enough,
    then the actual numbers (how many changes per minute, how many compute
    cycles and memory bytes, what's the likely cache hit rate for a given
    size cache, ...) need to be re-examined. I see no evidence of that
    re-examination -- am I missing something?

    > getdents(2) seems to work somehow.

    Yeah ... but we had to walk up hill, both ways, through 9 foot snow
    drifts, for years, summer and winter, to get there ;).

    > the kernel *has* that information already, ...

    Frustrating, isn't it. The information is right there, and we're trying
    to keep you from getting to it.

    Whatever ...

    > Off to do honest work,

    Good idea. Good luck with this. I rest my case, such as it be.

    -- 
                              I won't rest till it's the best ...
                              Programmer, Linux Scalability
                              Paul Jackson <pj@sgi.com> 1.650.933.1373
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    

  • Next message: Alan Cox: "PATCH: Kconfig for EDD"

    Relevant Pages

    • Re: UTF-8 and case-insensitivity
      ... >>but not enough to actually maintain a name cache in user space. ... Samba can use dnotify, ...
      (Linux-Kernel)
    • Re: silent semantic changes with reiser4
      ... it is time to shrink the cache and preferably ... dnotify or inotify but will be more efficient with them. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • RE: why swap at all?
      ... But this doesn't help in this case as the image-file is up to 4,4GB in ... whole which means that it ALONE can fill up the whole cache. ... Real Programmers consider "what you see is what you get" to be just as ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: statfs() / statvfs() syscall ballsup...
      ... regular writes and read stuff off the disk that was a potential security ... So right now we have extra code and extra complexity (which implies not ... through the page cache to make sure that it's safe. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • fastboot, diskstat
      ... that the total time for prefetching + actual boot was only 10% shorter, ... actually cache the pages I touched, ... Also, regarding the directory entries, are they accessed via the buffer ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)