From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [PATCH 00/21] mm: Preemptibility -v6 Date: Mon, 24 Jan 2011 15:24:44 +0100 Message-ID: <1295879084.28776.432.camel@laptop> References: <20101126143843.801484792@chello.nl> <1295457039.28776.137.camel@laptop> <1295873131.28776.431.camel@laptop> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1295873131.28776.431.camel@laptop> Sender: owner-linux-mm@kvack.org To: Hugh Dickins Cc: Andrew Morton , Benjamin Herrenschmidt , David Miller , Nick Piggin , Martin Schwidefsky , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, Andrea Arcangeli List-Id: linux-arch.vger.kernel.org On Mon, 2011-01-24 at 13:45 +0100, Peter Zijlstra wrote: > The only significant loser, I think, > > would be page reclaim (when concurrent with truncation): could spin for= a > > long time waiting for the i_mmap_mutex it expects would soon be dropped= ?=20 Well it won't spin (much) but mostly go to sleep if it really takes very long, but then, could it really take much longer than say a lock_page() when reclaim hits a page under IO? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org ([18.85.46.34]:56781 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751571Ab1AXOYH convert rfc822-to-8bit (ORCPT ); Mon, 24 Jan 2011 09:24:07 -0500 Subject: Re: [PATCH 00/21] mm: Preemptibility -v6 From: Peter Zijlstra In-Reply-To: <1295873131.28776.431.camel@laptop> References: <20101126143843.801484792@chello.nl> <1295457039.28776.137.camel@laptop> <1295873131.28776.431.camel@laptop> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Date: Mon, 24 Jan 2011 15:24:44 +0100 Message-ID: <1295879084.28776.432.camel@laptop> Mime-Version: 1.0 Sender: linux-arch-owner@vger.kernel.org List-ID: To: Hugh Dickins Cc: Andrew Morton , Benjamin Herrenschmidt , David Miller , Nick Piggin , Martin Schwidefsky , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, Andrea Arcangeli Message-ID: <20110124142444.-8WxBPRT0Z52zyq69y1boRKRTcs3uZVsb2et0LeONoA@z> On Mon, 2011-01-24 at 13:45 +0100, Peter Zijlstra wrote: > The only significant loser, I think, > > would be page reclaim (when concurrent with truncation): could spin for a > > long time waiting for the i_mmap_mutex it expects would soon be dropped? Well it won't spin (much) but mostly go to sleep if it really takes very long, but then, could it really take much longer than say a lock_page() when reclaim hits a page under IO?