From: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
To: Jianyu Zhan <nasa4836-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linux-MM <linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>,
Hillf Danton <dhillf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH] hugetlb_cgroup: explicitly init the early_init field
Date: Tue, 22 Apr 2014 15:14:33 +0800 [thread overview]
Message-ID: <535616D9.8060702@huawei.com> (raw)
In-Reply-To: <CAHz2CGXsvdtVdwZfyFAwtRHJ_vkeJZXtLv4fTGTYEeEwN7H6Qw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 2014/4/22 15:01, Jianyu Zhan wrote:
> Hi, hillf,
>
> On Tue, Apr 22, 2014 at 2:47 PM, Hillf Danton <dhillf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> But other fields still missed, if any. Fair?
>
> yep, it is not fair.
>
> 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 don't see how things can be improved by initializing it to 0 explicitly,
if anything needs to be improved.
WARNING: multiple messages have this Message-ID (diff)
From: Li Zefan <lizefan@huawei.com>
To: Jianyu Zhan <nasa4836@gmail.com>
Cc: Hillf Danton <dhillf@gmail.com>, Tejun Heo <tj@kernel.org>,
containers@lists.linux-foundation.org,
Cgroups <cgroups@vger.kernel.org>, Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] hugetlb_cgroup: explicitly init the early_init field
Date: Tue, 22 Apr 2014 15:14:33 +0800 [thread overview]
Message-ID: <535616D9.8060702@huawei.com> (raw)
In-Reply-To: <CAHz2CGXsvdtVdwZfyFAwtRHJ_vkeJZXtLv4fTGTYEeEwN7H6Qw@mail.gmail.com>
On 2014/4/22 15:01, Jianyu Zhan wrote:
> Hi, hillf,
>
> On Tue, Apr 22, 2014 at 2:47 PM, Hillf Danton <dhillf@gmail.com> wrote:
>> But other fields still missed, if any. Fair?
>
> yep, it is not fair.
>
> 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 don't see how things can be improved by initializing it to 0 explicitly,
if anything needs to be improved.
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Li Zefan <lizefan@huawei.com>
To: Jianyu Zhan <nasa4836@gmail.com>
Cc: Hillf Danton <dhillf@gmail.com>, Tejun Heo <tj@kernel.org>,
<containers@lists.linux-foundation.org>,
Cgroups <cgroups@vger.kernel.org>, Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] hugetlb_cgroup: explicitly init the early_init field
Date: Tue, 22 Apr 2014 15:14:33 +0800 [thread overview]
Message-ID: <535616D9.8060702@huawei.com> (raw)
In-Reply-To: <CAHz2CGXsvdtVdwZfyFAwtRHJ_vkeJZXtLv4fTGTYEeEwN7H6Qw@mail.gmail.com>
On 2014/4/22 15:01, Jianyu Zhan wrote:
> Hi, hillf,
>
> On Tue, Apr 22, 2014 at 2:47 PM, Hillf Danton <dhillf@gmail.com> wrote:
>> But other fields still missed, if any. Fair?
>
> yep, it is not fair.
>
> 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 don't see how things can be improved by initializing it to 0 explicitly,
if anything needs to be improved.
next prev parent reply other threads:[~2014-04-22 7:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-22 5:30 [PATCH] hugetlb_cgroup: explicitly init the early_init field Jianyu Zhan
2014-04-22 5:30 ` Jianyu Zhan
2014-04-22 6:47 ` Hillf Danton
2014-04-22 6:47 ` Hillf Danton
2014-04-22 7:01 ` Jianyu Zhan
2014-04-22 7:01 ` Jianyu Zhan
[not found] ` <CAHz2CGXsvdtVdwZfyFAwtRHJ_vkeJZXtLv4fTGTYEeEwN7H6Qw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-04-22 7:14 ` Li Zefan [this message]
2014-04-22 7:14 ` Li Zefan
2014-04-22 7:14 ` Li Zefan
[not found] ` <CAJd=RBA6ZUZ2UBetmcwGciqY8snme-aY60ZhW9F=8CO6kDzMBA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-04-22 7:01 ` Jianyu Zhan
[not found] ` <1398144620-9630-1-git-send-email-nasa4836-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-04-22 6:47 ` Hillf Danton
-- strict thread matches above, loose matches on Subject: below --
2014-04-22 5:30 Jianyu Zhan
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=535616D9.8060702@huawei.com \
--to=lizefan-hv44wf8li93qt0dzr+alfa@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=dhillf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=nasa4836-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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.