From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id E0662B6F14 for ; Mon, 21 Mar 2011 12:51:00 +1100 (EST) Subject: Re: mmotm threatens ppc preemption again From: Benjamin Herrenschmidt To: Hugh Dickins In-Reply-To: References: <1300665188.2402.64.camel@pasglop> Content-Type: text/plain; charset="UTF-8" Date: Mon, 21 Mar 2011 12:50:07 +1100 Message-ID: <1300672207.2402.205.camel@pasglop> Mime-Version: 1.0 Cc: Jeremy Fitzhardinge , linuxppc-dev@lists.ozlabs.org, Andrew Morton , Peter Zijlstra List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Sun, 2011-03-20 at 18:41 -0700, Hugh Dickins wrote: > > I don't know what the right way to fix that is. We have an absolute > > requirement that the batching we start within a lazy MMU section > > is complete and flushed before any other PTE in that section can be > > touched by anything else. Do we -at least- keep that guarantee ? > > I'm guessing it's a guarantee of the same kind as led me to skip > page_table_lock on init_mm in 2.6.15: no locking to guarantee it, > but it would have to be a kernel bug, in a driver or wherever, > for us to be accessing such a section while it was in transit > (short of speculative access prior to tlb flush). As long as the races to avoid are between map/unmap vs. access, yes, it -should- be fine, and we used to not do demand faulting on kernel space (but for how long ?). I'm wondering why we don't just stick a ptl in there or is there a good reason why we can't ? > I don't see where you're doing batching on init_mm today: > it looks as if Jeremy's patches, by using the same code as he has > for user mms, are now enabling batching on init_mm, and you should :-) > > But I may be all wrong: it's between you and Jeremy, > and until he defends them, his patches should not go forward. We don't do it today (batching). Jeremy's patches have the side effect of "enabling" it, which isn't wrong per-se ... but on our side relies on some locking assumptions we are missing. Cheers, Ben.