From: Li Zefan <lizefan@huawei.com>
To: Jianyu Zhan <nasa4836@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>, <a.p.zijlstra@chello.nl>,
<paulus@samba.org>, <mingo@redhat.com>, <acme@kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] perf-event/cgroup: explicitly init the early_init field
Date: Tue, 22 Apr 2014 17:31:53 +0800 [thread overview]
Message-ID: <53563709.2000408@huawei.com> (raw)
In-Reply-To: <CAHz2CGW0D6GpbP7Tps2KoN8av_OUEzO9xGvpV_XwoHgFQ36sOw@mail.gmail.com>
On 2014/4/22 15:12, Jianyu Zhan wrote:
> On Tue, Apr 22, 2014 at 2:06 PM, Ingo Molnar <mingo@kernel.org> wrote:
>> How can that field ever be nonzero?
>>
>> I.e. under what exact circumstances does this patch make sense?
>
> Hi, Ingo,
>
> More explanation.
>
> Sure, for this global variable struct, if not initailized, its all
> fields will be initialized
> to 0 or null(depending on its type). The point here is no to deprive
> the rights of compiler/linker of doing this initialization, it is mainly for
> documentation reason. Actually this field's value would affect how ->css_alloc
> should implemented.
>
> Concretely, if early_init is nonzero, then ->css_alloc *must not* call kzalloc,
> because in cgroup implementation, ->css_alloc will be called earlier before
> mm_init().
>
> I don't think that the value of one field(early_init) has a so subtle
> restrition on the another field(css_alloc) is a good thing,
> but since
> it is there,
> docment it should be needed.
>
> I could resend the patch with more comment.
>
nack
As I said in another mail thread, this change makes no sense.
prev parent reply other threads:[~2014-04-22 9:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-22 5:28 [PATCH] perf-event/cgroup: explicitly init the early_init field Jianyu Zhan
2014-04-22 6:06 ` Ingo Molnar
2014-04-22 6:42 ` Jianyu Zhan
2014-04-22 7:12 ` Jianyu Zhan
2014-04-22 9:31 ` Li Zefan [this message]
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=53563709.2000408@huawei.com \
--to=lizefan@huawei.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=nasa4836@gmail.com \
--cc=paulus@samba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.