Re: [RFC][PATCH] inotify 0.9

[Robert Love]

On Thu, 2004-09-16 at 18:34 -0400, Bill Davidsen wrote:

> >   Maybe you should not be so fast in using your flamethrower;)
> 
> I didn't intend this as a flame, but I do feel this implementation doesn't
> scale. I offered another approach off the top of my head, which appears to
> me to be more scalable. I claimed no expertise, I just made a suggestion,
> based on my first thought on how I would attack the problem in a way which
> appears more scalable.

The thing you are missing is that you absolutely have to pin something
or you have multiple VFS races.  Your bitmap suggestion, while cute,
really shows a lack of understanding of the problem space.

dnotify had to do it, inotify has to do it.

Do you want to go down the lets-find-a-race path with Al Viro? ;-)

> If we are going to 4k stack because larger memory blocks are hard to find,
> I have to suspect that anything which locks up blocks size in MB is going
> to cause problems. I didn't even ask what would happen on NUMA machines,
> because that's not my usual concern.

It is not the total size that is the concern, but the per-allocation
size, which has to be contiguous.  A first order allocation is hard to
do.  You can only find two contiguous free pages in physical memory so
often.

Inodes come from the slabcache.  NONE of this is an issue there.

Plus, as I have said, the slabcache is probably caching much of what you
are pinning.  So memory consumption is not changed.  Finally, these
numbers are WORST case.  Watch only a handful of files and you have a
handful of hundreds of bytes pinned.

	Robert Love


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/