Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261279AbVD3QaH (ORCPT ); Sat, 30 Apr 2005 12:30:07 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261280AbVD3QaH (ORCPT ); Sat, 30 Apr 2005 12:30:07 -0400 Received: from ms-smtp-01.texas.rr.com ([24.93.47.40]:54476 "EHLO ms-smtp-01-eri0.texas.rr.com") by vger.kernel.org with ESMTP id S261279AbVD3QaC (ORCPT ); Sat, 30 Apr 2005 12:30:02 -0400 Subject: Re: [PATCH] cifs: handle termination of cifs oplockd kernel thread From: Steve French To: Miklos Szeredi Cc: hch@infradead.org, 7eggert@gmx.de, linux-kernel@vger.kernel.org In-Reply-To: References: <3YLdQ-4vS-15@gated-at.bofh.it> <20050430073238.GA22673@infradead.org> <20050430082952.GA23253@infradead.org> <427387FB.4030901@austin.rr.com> Content-Type: text/plain Message-Id: <1114874844.5119.9.camel@smfhome.smfdom> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Sat, 30 Apr 2005 10:27:24 -0500 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1362 Lines: 25 On Sat, 2005-04-30 at 11:16, Miklos Szeredi wrote: > The big problem is the page cache, because that is not limited. The > user can mmap huge amounts of memory, dirty them, and then when the > machine runs out of memory, and writeback kicks in, it may already be > too late. Yes - we have seen the inode caching get too aggressive in testcases with paired machines each mounting two clients and also running two servers - in particular running an NFS and CIFS mounts from the same client to a server running nfsd and Samba, and then doing the reverse and launching large file copy testcases going both directions at the same time. To make it nastier they add exports for Samba and NFS of more than one local filesystem type. Fortunately most of the issues there have been fixed, but it is an incredibly hard thing to guarantee that there is enough memory in those cases because so much is taken up by the page manager doing inode data caching and multimachine deadlock could occur if the server is blocked on a client doing writepage which is blocked on the other server which is blocked on the other client ... - 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/