From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail143.messagelabs.com (mail143.messagelabs.com [216.82.254.35]) by kanga.kvack.org (Postfix) with SMTP id 5CEFD6B002E for ; Fri, 7 Oct 2011 13:03:47 -0400 (EDT) Date: Fri, 7 Oct 2011 12:03:43 -0500 (CDT) From: Christoph Lameter Subject: Re: [PATCH 0/5] Slab objects identifiers In-Reply-To: <4E8DD5B9.4060905@parallels.com> Message-ID: References: <4E8DD5B9.4060905@parallels.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Pavel Emelyanov Cc: Pekka Enberg , Matt Mackall , linux-mm@kvack.org, Glauber Costa , Cyrill Gorcunov , Andrew Morton On Thu, 6 Oct 2011, Pavel Emelyanov wrote: > While doing the checkpoint-restore in the userspace we need to determine > whether various kernel objects (like mm_struct-s of file_struct-s) are shared > between tasks and restore this state. > > The 2nd step can for now be solved by using respective CLONE_XXX flags and > the unshare syscall, while there's currently no ways for solving the 1st one. > > One of the ways for checking whether two tasks share e.g. an mm_struct is to > provide some mm_struct ID of a task to its proc file. The best from the > performance point of view ID is the object address in the kernel, but showing > them to the userspace is not good for performance reasons. Thus the ID should > not be calculated based on the object address. If two tasks share an mm_struct then the mm_struct pointer (task->mm) will point to the same address. Objects are already uniquely identified by their address. If you store the physical address with the object content when transferring then you can verify that they share the mm_struct. -- 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 internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org