From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1753624AbZIKQ6P@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753624AbZIKQ6P (ORCPT <rfc822;w@1wt.eu>);
	Fri, 11 Sep 2009 12:58:15 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753323AbZIKQ6P
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Fri, 11 Sep 2009 12:58:15 -0400
Received: from sj-iport-2.cisco.com ([171.71.176.71]:20919 "EHLO
	sj-iport-2.cisco.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751519AbZIKQ6O (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 11 Sep 2009 12:58:14 -0400
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAP8dqkqrR7PE/2dsb2JhbADFJYhIAZAMBYQY
X-IronPort-AV: E=Sophos;i="4.44,371,1249257600"; 
   d="scan'208";a="203870132"
From: Roland Dreier <rdreier@cisco.com>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Brice Goglin <Brice.Goglin@inria.fr>,
       KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
       linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
       general@lists.openfabrics.org, akpm@linux-foundation.org,
       torvalds@linux-foundation.org
Subject: Re: [ofa-general] Re: [GIT PULL] please pull ummunotify
References: <aday6omhz9d.fsf@cisco.com>
	<20090911145036.DB65.A69D9226@jp.fujitsu.com>
	<adatyzahvbm.fsf@cisco.com> <4AA9EAF7.5010401@inria.fr>
	<adapr9yhug3.fsf@cisco.com>
	<20090911064019.GZ4973@obsidianresearch.com>
X-Message-Flag: Warning: May contain useful information
Date: Fri, 11 Sep 2009 09:58:10 -0700
In-Reply-To: <20090911064019.GZ4973@obsidianresearch.com> (Jason Gunthorpe's
	message of "Fri, 11 Sep 2009 00:40:19 -0600")
Message-ID: <adaljklifkt.fsf@cisco.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-OriginalArrivalTime: 11 Sep 2009 16:58:16.0678 (UTC) FILETIME=[0E9F3860:01CA3301]
Authentication-Results: sj-dkim-4; header.From=rdreier@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim4002 verified; ); 
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


 > So.. What is the problem with fork? The semantics of what should
 > happen seem natural enough to me, the PD doesn't get copied to the
 > child, so the MR stays with the parent. COW events on the pinned
 > region must be resolved so that the physical page stays with the
 > process that has pinned it - the pin is logically released in the
 > child because the MR doesn't exist because the PD doesn't exist.

This is getting away from the problem that ummunotify is solving, but
handling a COW fault generated by the parent by doing the copy in the
child seems like a pretty major, tricky change to make.  The child may
have forked 100 more times in the meantime, meaning we now have to
change 101 memory maps ... the cost of page faults goes through the roof
probably...

 - R.