Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261417AbVAMDKp (ORCPT ); Wed, 12 Jan 2005 22:10:45 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261422AbVAMDKK (ORCPT ); Wed, 12 Jan 2005 22:10:10 -0500 Received: from bay-bridge.veritas.com ([143.127.3.10]:15111 "EHLO MTVMIME03.enterprise.veritas.com") by vger.kernel.org with ESMTP id S261451AbVAMDJq (ORCPT ); Wed, 12 Jan 2005 22:09:46 -0500 Date: Thu, 13 Jan 2005 03:09:14 +0000 (GMT) From: Hugh Dickins X-X-Sender: hugh@localhost.localdomain To: Nick Piggin cc: Andrew Morton , , , , , , , Subject: Re: page table lock patch V15 [0/7]: overview In-Reply-To: <41E5B7AD.40304@yahoo.com.au> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1296 Lines: 29 On Thu, 13 Jan 2005, Nick Piggin wrote: > Andrew Morton wrote: > > Note that this was with my ptl removal patches. I can't see why Christoph's > would have _any_ extra overhead as they are, but it looks to me like they're > lacking in atomic ops. So I'd expect something similar for Christoph's when > they're properly atomic. > > > Look, -7% on a 2-way versus +700% on a many-way might well be a tradeoff we > > agree to take. But we need to fully understand all the costs and benefits. > > I think copy_page_range is the one to keep an eye on. Christoph's currently lack set_pte_atomics in the fault handlers, yes. But I don't see why they should need set_pte_atomics in copy_page_range (which is why I persuaded him to drop forcing set_pte to atomic). dup_mmap has down_write of the src mmap_sem, keeping out any faults on that. copy_pte_range has spin_lock of the dst page_table_lock and the src page_table_lock, keeping swapout away from those. Why would atomic set_ptes be needed there? Probably in yours, but not in Christoph's. Hugh - 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/