From: Pavel Emelyanov <xemul@parallels.com>
To: Christoph Lameter <cl@linux-foundation.org>,
Pekka Enberg <penberg@kernel.org>, Matt Mackall <mpm@selenic.com>,
linux-mm@kvack.org
Cc: Glauber Costa <glommer@parallels.com>,
Cyrill Gorcunov <gorcunov@openvz.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: [PATCH 0/5] Slab objects identifiers
Date: Thu, 06 Oct 2011 20:22:17 +0400 [thread overview]
Message-ID: <4E8DD5B9.4060905@parallels.com> (raw)
Hi.
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.
The proposal is to have the ID for slab objects as the mixture of two things -
the number of an object on the slub and the ID of a slab, which is calculated
simply by getting a monotonic 64 bit number at the slab allocation time which
gives us 200+ years of stable work (see comment in the patch #2) :)
Thanks,
Pavel
--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2011-10-06 16:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-06 16:22 Pavel Emelyanov [this message]
2011-10-06 16:23 ` [PATCH 1/5] slab: Tossing bits around Pavel Emelyanov
2011-10-06 16:23 ` [PATCH 2/5] slab_id: Generic slab ID infrastructure Pavel Emelyanov
2011-10-07 8:27 ` Glauber Costa
2011-10-07 8:31 ` Pavel Emelyanov
2011-10-06 16:23 ` [PATCH 3/5] slab_id: Slab support for IDs Pavel Emelyanov
2011-10-06 16:24 ` [PATCH 4/5] slab_id: Slub " Pavel Emelyanov
2011-10-06 16:24 ` [PATCH 5/5] slab_id: Show the task's mm ID in proc Pavel Emelyanov
2011-10-07 17:03 ` [PATCH 0/5] Slab objects identifiers Christoph Lameter
2011-10-10 10:20 ` Pavel Emelyanov
2011-10-10 15:24 ` Christoph Lameter
2011-10-10 15:46 ` Pavel Emelyanov
2011-10-13 7:12 ` Pekka Enberg
2011-10-13 11:25 ` Pavel Emelyanov
2011-10-13 12:12 ` Pekka Enberg
2011-10-13 12:23 ` Pavel Emelyanov
2011-10-10 18:59 ` Matt Helsley
2011-10-11 7:50 ` Pavel Emelyanov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E8DD5B9.4060905@parallels.com \
--to=xemul@parallels.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=glommer@parallels.com \
--cc=gorcunov@openvz.org \
--cc=linux-mm@kvack.org \
--cc=mpm@selenic.com \
--cc=penberg@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox