On Tue, 2008-08-05 at 11:27 -0700, Arjan van de Ven wrote:Thankfully my implementation will invalidate that close time check and caching result. It does the invalidating the same place we update mtime and my understanding is that mmap has been updating mtime for quite a while now. So again, it might not be perfect, but that situation should get caught the next time around. I see close time checking as more of a performance win and as a way to help close some of the length bad information could exist than anything since its done in a non-blocking path. I think we all agree that open is the most interesting time for scanning operations, but as Jonathan points out there is some value (even if not perfect value) in looking at closes as well. I actually already have an async non-blocking close notification built in. Instead of waiting for a userspace response we just queue the close notification and move along. When userspace gets around to it scanning and allow/deny caching can then take place at a later time. -Eric --
| Ingo Molnar | Re: x86: 4kstacks default |
| Stephen Rothwell | Re: Announce: Linux-next (Or Andrew's dream :-)) |
| Trent Piepho | [PATCH] [POWERPC] Improve (in|out)_beXX() asm code |
| Rafael J. Wysocki | [Bug #10919] [regression] display dimming is slow and laggy - Acer Travelmate 661lci |
git: | |
| Linus Torvalds | Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 |
| Andrew Morton | Re: [BUG] New Kernel Bugs |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
