From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: simultaneous creates in a directory Date: Fri, 27 Sep 2002 14:08:38 -0700 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <3D94C8D6.5C07D7F2@digeo.com> References: <20020927150249.B27592@parcelfarce.linux.theplanet.co.uk> <3D94B512.2BDF1840@digeo.com> <20020927204425.GT22942@holomorphy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Matthew Wilcox , linux-fsdevel@vger.kernel.org, dwmw2@infradead.org Return-path: Received: from digeo-nav01.digeo.com (digeo-nav01.digeo.com [192.168.1.233]) by packet.digeo.com (8.9.3+Sun/8.9.3) with SMTP id OAA07930 for ; Fri, 27 Sep 2002 14:08:34 -0700 (PDT) To: William Lee Irwin III List-Id: linux-fsdevel.vger.kernel.org William Lee Irwin III wrote: > > > Even then, do we care? Well hrm. One page of ZONE_NORMAL per process > > doesn't sound like the end of the world... > > Well, it's one of the larger contributors to one of my OOM scenarios, doom scenarios more like ;) > which is why I asked willy to do it. Also consider /tmp/ ... > Does Matthew's patch actually work? Seems that we have to perform lookups while holding that memory, and that requires taking i_sem. It's hard to get very excited about the seriousness of this problem, I must say. Any idea why the opens are taking so long? Maybe someone is throttled on writeback while holding i_sem? It would be interesting to actually hunt down the current i_sem holder and see what he's up to. That's pretty easy: struct task_struct *wli_task; down(&dir->i_sem); wli_task = current; then go poke at wli_task in kgdb.