Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 17 Sep 2002 03:53:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 17 Sep 2002 03:53:50 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]:40869 "EHLO smtpde02.sap-ag.de") by vger.kernel.org with ESMTP id ; Tue, 17 Sep 2002 03:53:50 -0400 From: Christoph Rohland To: Hugh Dickins Cc: Andrew Morton , William Lee Irwin III , , Subject: Re: dbench on tmpfs OOM's References: Organisation: Development SAP J2EE Engine Date: Tue, 17 Sep 2002 09:57:18 +0200 In-Reply-To: (Hugh Dickins's message of "Tue, 17 Sep 2002 08:01:20 +0100 (BST)") Message-ID: User-Agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.4 (Common Lisp (Windows [3]), i586-pc-win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SAP: out X-SAP: out X-SAP: out X-SAP: out X-SAP: out Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1103 Lines: 23 Hi Hugh, On Tue, 17 Sep 2002, Hugh Dickins wrote: > What I never did was try GFP_HIGHUSER and kmap on the index pages: > I think I decided back then that it wasn't likely to be needed > (sparsely filled file indexes are a rarer case than sparsely filled > pagetables, once the stupidity is fixed; and small files don't use > index pages at all). But Bill's testing may well prove me wrong. I think that this would be a good improvement. Big database and application servers would definitely benefit from it, desktops could easier use tmpfs as temporary file systems. I never dared to do it with my limited time since I feared deadlock situations. Also I ended up that I would try to go one step further: Make the index pages swappable, i.e. make the directory nodes normal tmpfs files. This would even make the accounting right. Greetings Christoph - 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/