From: Pavel Emelyanov <xemul@parallels.com>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Christoph Lameter <cl@gentwo.org>, Matt Mackall <mpm@selenic.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Glauber Costa <glommer@parallels.com>,
Cyrill Gorcunov <gorcunov@openvz.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 0/5] Slab objects identifiers
Date: Thu, 13 Oct 2011 15:25:55 +0400 [thread overview]
Message-ID: <4E96CAC3.3040402@parallels.com> (raw)
In-Reply-To: <CAOJsxLGctbXuXNuCWukH6LayZkuKH=aTx1L7uk87gVbVOJ_MKg@mail.gmail.com>
On 10/13/2011 11:12 AM, Pekka Enberg wrote:
> On Mon, Oct 10, 2011 at 1:20 PM, Pavel Emelyanov <xemul@parallels.com> wrote:
>>> 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.
>>
>> Yes of course, but ...
>>
>>> If you store the physical address with the object content
>>> when transferring then you can verify that they share the mm_struct.
>>
>> ... are we all OK with showing kernel addresses to the userspace? I thought the %pK
>> format was invented specially to handle such leaks.
>
> I don't think it's worth it to try to hide kernel addresses for
> checkpoint/restart.
We don't need to know anything about kernel internals for checkpoint-restart, that's
why I said, that abstract identifiers are just fine.
>> If we are, then (as I said in the first letter) we should just show them and forget
>> this set. If we're not - we should invent smth more straightforward and this set is
>> an attempt for doing this.
>
> Does this ID thing need to happen in the slab layer?
Not necessarily, of course, but if we're going to show some identifier of an object
we have 2 choices - either we generate this ID independently (with e.g. IDA), but
this is slow, or we use some knowledge of an object as a bunch of bytes in memory.
These slab IDs thing is an attempt to implement the 2nd approach.
The question I'm trying to answer with this is - do task A and task B have their mm
shared or not? Showing an ID answers one. Maybe there exists another way, but I haven't
invented it yet and decided to send this set out for discussion (the "release early"
idiom). If slab maintainers say "no, we don't accept this at all ever", then of course
I'll have to think further, but if the concept is suitable, but needs some refinement -
let's do it.
> Pekka
> .
>
--
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 prev parent reply other threads:[~2011-10-13 11:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-06 16:22 Pavel Emelyanov
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 [this message]
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=4E96CAC3.3040402@parallels.com \
--to=xemul@parallels.com \
--cc=akpm@linux-foundation.org \
--cc=cl@gentwo.org \
--cc=glommer@parallels.com \
--cc=gorcunov@openvz.org \
--cc=linux-mm@kvack.org \
--cc=mpm@selenic.com \
--cc=penberg@cs.helsinki.fi \
/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