Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261276AbUK0RRF (ORCPT ); Sat, 27 Nov 2004 12:17:05 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261272AbUK0RQI (ORCPT ); Sat, 27 Nov 2004 12:16:08 -0500 Received: from gprs214-89.eurotel.cz ([160.218.214.89]:49793 "EHLO amd.ucw.cz") by vger.kernel.org with ESMTP id S261269AbUK0ROT (ORCPT ); Sat, 27 Nov 2004 12:14:19 -0500 Date: Sat, 27 Nov 2004 18:13:18 +0100 From: Pavel Machek To: Rik van Riel Cc: Miklos Szeredi , akpm@osdl.org, torvalds@osdl.org, hbryan@us.ibm.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] [Request for inclusion] Filesystem in Userspace Message-ID: <20041127171318.GA1319@elf.ucw.cz> References: <20041118130601.6ee8bd97.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Warning: Reading this can be dangerous to your mental health. User-Agent: Mutt/1.5.6+20040722i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1706 Lines: 46 Hi! > >The solution I'm thinking is along the lines of accounting the number > >of writable pages assigned to FUSE filesystems. Limiting this should > >solve the deadlock problem. This would only impact performance for > >shared writable mappings, which are rare anyway. > > Note that NFS, and any filesystems on iSCSI or g/e/ndb block > devices have the exact same problem. To explain why this is > the case, lets start with the VM allocation and pageout > thresholds: > > pages_min ------------------ > > GFP_ATOMIC ------------------ > > PF_MEMALLOC ------------------ > > 0 ------------------ > > When writing out a dirty page, the pageout code is allowed > to allocate network buffers down to the PF_MEMALLOC boundary. > > However, when receiving the ACK network packets from the server, > the network stack is only allowed to allocate memory down to the > GFP_ATOMIC watermark. Ouch... Shame on me, I never realized that this is a problem. I knew that swapping over nbd does not work, but I did not realize that writeout is as critical as swapping... :-(. This means that read/write nbd is pretty bad idea. I wonder why it is not broken for people? Probably noone uses so big ammount of data over nbd... Can you describe that solution? You can do it anonymously if you want to ;-)))). Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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/