From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Paris Subject: Re: A few concerns about fanotify implementation. Date: Mon, 06 Jun 2011 09:43:05 -0400 Message-ID: <1307367787.2052.6.camel@localhost.localdomain> References: <1288095195.29745.4010.camel@novikov-v> <201010261358.46974.tvrtko.ursulin@sophos.com> <1288169699.7715.103.camel@novikov-v> <1288195134.2655.202.camel@localhost.localdomain> <4DE8ACAD.2080003@kaspersky.com> <4DEC9B86.6060506@kaspersky.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "malware-list-h+Im9A44IAFcMpApZELgcQ@public.gmane.org" , Douglas Leeder To: Vasily Novikov Return-path: In-Reply-To: <4DEC9B86.6060506-BkmlMuIjteXqlBn2x/YWAg@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: malware-list-bounces-h+Im9A44IAFcMpApZELgcQ@public.gmane.org Errors-To: malware-list-bounces-h+Im9A44IAFcMpApZELgcQ@public.gmane.org List-Id: linux-fsdevel.vger.kernel.org On Mon, 2011-06-06 at 13:19 +0400, Vasily Novikov wrote: > >> 2. We can't use unlimited cache because it can potentially grab too much > >> memory and slow down a system. In case we use limited cache it can be > >> easily filled with not very frequently used files. So the only option we > >> have at the moment is to clear cache every time it is full. > >> The solution we consider the most appropriate is to introduce > >> replaceable marks and LRU cache for them in fanotify. > >> So we suggest to introduce a new flag FAN_MARK_REPLACEABLE for marks. > > > > IIRC the cache is stored in the inodes themselves, so will automatically > > be culled as inodes are pushed out of memory? > > If I understood the code correctly there is no cache by itself. It's > just implemented through marks and it's ignored_mask field. So there is > a list of marks for each inode that is empty initially. But when you add > mark to this list you allocate fsnotify_mark structure which is about 64 > bytes. Well, you are both correct. If you add a mark with only 'ignored' events set it will not pin the inode into the kernel. If the system starts to get under memory pressure the kernel will kick unused inodes and any associated ignored marks out of ram. Inodes with 'real' events attached will be pinned in memory and cannot be evicted under memory pressure. -Eric