From: Simon Jeons <simon.jeons-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>
Cc: Liujiang <jiang.liu-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
dhillf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
Jianguo Wu <wujianguo-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Hanjun Guo <guohanjun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
Xishi Qiu <qiuxishi-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Jiang Liu <liuj97-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
aneesh.kumar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org
Subject: Re: [PATCH] mm/hugetlb: create hugetlb cgroup file in hugetlb_init
Date: Wed, 12 Dec 2012 23:12:14 -0600 [thread overview]
Message-ID: <1355375534.1567.1.camel@kernel.cn.ibm.com> (raw)
In-Reply-To: <20121212112329.GE32081-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
On Wed, 2012-12-12 at 12:23 +0100, Michal Hocko wrote:
> On Wed 12-12-12 18:44:13, Xishi Qiu wrote:
> > On 2012/12/12 18:19, Michal Hocko wrote:
> >
> > > On Wed 12-12-12 16:25:59, Jianguo Wu wrote:
> > >> Build kernel with CONFIG_HUGETLBFS=y,CONFIG_HUGETLB_PAGE=y
> > >> and CONFIG_CGROUP_HUGETLB=y, then specify hugepagesz=xx boot option,
> > >> system will boot fail.
> > >>
> > >> This failure is caused by following code path:
> > >> setup_hugepagesz
> > >> hugetlb_add_hstate
> > >> hugetlb_cgroup_file_init
> > >> cgroup_add_cftypes
> > >> kzalloc <--slab is *not available* yet
> > >>
> > >> For this path, slab is not available yet, so memory allocated will be
> > >> failed, and cause WARN_ON() in hugetlb_cgroup_file_init().
> > >>
> > >> So I move hugetlb_cgroup_file_init() into hugetlb_init().
> > >
> > > I do not think this is a good idea. hugetlb_init is in __init section as
> > > well so what guarantees that the slab is initialized by then? Isn't this
> > > just a good ordering that makes this working?
> >
> > Hi Michal,
> >
> > __initcall functions will be called in
> > start_kernel()
> > rest_init() // -> slab is already
> > kernel_init()
> > kernel_init_freeable()
> > do_basic_setup()
> > do_initcalls()
> >
> > and setup_hugepagesz() will be called in
> > start_kernel()
> > parse_early_param() // -> before mm_init() -> kmem_cache_init()
> >
> > Is this right?
>
> Yes this is right. I just noticed that kmem_cache_init_late is an __init
> function as well and didn't realize it is called directly. Sorry about
> the confusion.
> Anyway I still think it would be a better idea to move the call into the
> hugetlb_cgroup_create callback where it is more logical IMO but now that
> I'm looking at other controllers (blk and kmem.tcp) they all do this from
> init calls as well. So it doesn't make sense to have hugetlb behave
> differently.
Which callback in cgroup_subsys should hugetlb_cgroup_create associated?
Currently, there is no such callback.
>
> So
> Acked-by: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>
>
> Thanks!
WARNING: multiple messages have this Message-ID (diff)
From: Simon Jeons <simon.jeons@gmail.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: Xishi Qiu <qiuxishi@huawei.com>,
Jianguo Wu <wujianguo@huawei.com>,
tj@kernel.org, lizefan@huawei.com,
aneesh.kumar@linux.vnet.ibm.com,
Andrew Morton <akpm@linux-foundation.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Liujiang <jiang.liu@huawei.com>,
dhillf@gmail.com, Jiang Liu <liuj97@gmail.com>,
Hanjun Guo <guohanjun@huawei.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
containers@lists.linux-foundation.org, cgroups@vger.kernel.org
Subject: Re: [PATCH] mm/hugetlb: create hugetlb cgroup file in hugetlb_init
Date: Wed, 12 Dec 2012 23:12:14 -0600 [thread overview]
Message-ID: <1355375534.1567.1.camel@kernel.cn.ibm.com> (raw)
In-Reply-To: <20121212112329.GE32081@dhcp22.suse.cz>
On Wed, 2012-12-12 at 12:23 +0100, Michal Hocko wrote:
> On Wed 12-12-12 18:44:13, Xishi Qiu wrote:
> > On 2012/12/12 18:19, Michal Hocko wrote:
> >
> > > On Wed 12-12-12 16:25:59, Jianguo Wu wrote:
> > >> Build kernel with CONFIG_HUGETLBFS=y,CONFIG_HUGETLB_PAGE=y
> > >> and CONFIG_CGROUP_HUGETLB=y, then specify hugepagesz=xx boot option,
> > >> system will boot fail.
> > >>
> > >> This failure is caused by following code path:
> > >> setup_hugepagesz
> > >> hugetlb_add_hstate
> > >> hugetlb_cgroup_file_init
> > >> cgroup_add_cftypes
> > >> kzalloc <--slab is *not available* yet
> > >>
> > >> For this path, slab is not available yet, so memory allocated will be
> > >> failed, and cause WARN_ON() in hugetlb_cgroup_file_init().
> > >>
> > >> So I move hugetlb_cgroup_file_init() into hugetlb_init().
> > >
> > > I do not think this is a good idea. hugetlb_init is in __init section as
> > > well so what guarantees that the slab is initialized by then? Isn't this
> > > just a good ordering that makes this working?
> >
> > Hi Michal,
> >
> > __initcall functions will be called in
> > start_kernel()
> > rest_init() // -> slab is already
> > kernel_init()
> > kernel_init_freeable()
> > do_basic_setup()
> > do_initcalls()
> >
> > and setup_hugepagesz() will be called in
> > start_kernel()
> > parse_early_param() // -> before mm_init() -> kmem_cache_init()
> >
> > Is this right?
>
> Yes this is right. I just noticed that kmem_cache_init_late is an __init
> function as well and didn't realize it is called directly. Sorry about
> the confusion.
> Anyway I still think it would be a better idea to move the call into the
> hugetlb_cgroup_create callback where it is more logical IMO but now that
> I'm looking at other controllers (blk and kmem.tcp) they all do this from
> init calls as well. So it doesn't make sense to have hugetlb behave
> differently.
Which callback in cgroup_subsys should hugetlb_cgroup_create associated?
Currently, there is no such callback.
>
> So
> Acked-by: Michal Hocko <mhocko@suse.cz>
>
> Thanks!
--
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: Simon Jeons <simon.jeons@gmail.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: Xishi Qiu <qiuxishi@huawei.com>,
Jianguo Wu <wujianguo@huawei.com>,
tj@kernel.org, lizefan@huawei.com,
aneesh.kumar@linux.vnet.ibm.com,
Andrew Morton <akpm@linux-foundation.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Liujiang <jiang.liu@huawei.com>,
dhillf@gmail.com, Jiang Liu <liuj97@gmail.com>,
Hanjun Guo <guohanjun@huawei.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
containers@lists.linux-foundation.org, cgroups@vger.kernel.org
Subject: Re: [PATCH] mm/hugetlb: create hugetlb cgroup file in hugetlb_init
Date: Wed, 12 Dec 2012 23:12:14 -0600 [thread overview]
Message-ID: <1355375534.1567.1.camel@kernel.cn.ibm.com> (raw)
In-Reply-To: <20121212112329.GE32081@dhcp22.suse.cz>
On Wed, 2012-12-12 at 12:23 +0100, Michal Hocko wrote:
> On Wed 12-12-12 18:44:13, Xishi Qiu wrote:
> > On 2012/12/12 18:19, Michal Hocko wrote:
> >
> > > On Wed 12-12-12 16:25:59, Jianguo Wu wrote:
> > >> Build kernel with CONFIG_HUGETLBFS=y,CONFIG_HUGETLB_PAGE=y
> > >> and CONFIG_CGROUP_HUGETLB=y, then specify hugepagesz=xx boot option,
> > >> system will boot fail.
> > >>
> > >> This failure is caused by following code path:
> > >> setup_hugepagesz
> > >> hugetlb_add_hstate
> > >> hugetlb_cgroup_file_init
> > >> cgroup_add_cftypes
> > >> kzalloc <--slab is *not available* yet
> > >>
> > >> For this path, slab is not available yet, so memory allocated will be
> > >> failed, and cause WARN_ON() in hugetlb_cgroup_file_init().
> > >>
> > >> So I move hugetlb_cgroup_file_init() into hugetlb_init().
> > >
> > > I do not think this is a good idea. hugetlb_init is in __init section as
> > > well so what guarantees that the slab is initialized by then? Isn't this
> > > just a good ordering that makes this working?
> >
> > Hi Michal,
> >
> > __initcall functions will be called in
> > start_kernel()
> > rest_init() // -> slab is already
> > kernel_init()
> > kernel_init_freeable()
> > do_basic_setup()
> > do_initcalls()
> >
> > and setup_hugepagesz() will be called in
> > start_kernel()
> > parse_early_param() // -> before mm_init() -> kmem_cache_init()
> >
> > Is this right?
>
> Yes this is right. I just noticed that kmem_cache_init_late is an __init
> function as well and didn't realize it is called directly. Sorry about
> the confusion.
> Anyway I still think it would be a better idea to move the call into the
> hugetlb_cgroup_create callback where it is more logical IMO but now that
> I'm looking at other controllers (blk and kmem.tcp) they all do this from
> init calls as well. So it doesn't make sense to have hugetlb behave
> differently.
Which callback in cgroup_subsys should hugetlb_cgroup_create associated?
Currently, there is no such callback.
>
> So
> Acked-by: Michal Hocko <mhocko@suse.cz>
>
> Thanks!
next prev parent reply other threads:[~2012-12-13 5:12 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-12 8:25 [PATCH] mm/hugetlb: create hugetlb cgroup file in hugetlb_init Jianguo Wu
2012-12-12 8:25 ` Jianguo Wu
2012-12-12 8:25 ` Jianguo Wu
[not found] ` <50C83F97.3040009-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2012-12-12 10:19 ` Michal Hocko
2012-12-12 10:19 ` Michal Hocko
2012-12-12 10:19 ` Michal Hocko
2012-12-12 10:44 ` Xishi Qiu
2012-12-12 10:44 ` Xishi Qiu
[not found] ` <50C85FFD.10305-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2012-12-12 11:23 ` Michal Hocko
2012-12-12 11:23 ` Michal Hocko
2012-12-12 11:23 ` Michal Hocko
[not found] ` <20121212112329.GE32081-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-12-12 12:48 ` Michal Hocko
2012-12-12 12:48 ` Michal Hocko
2012-12-12 12:48 ` Michal Hocko
2012-12-12 12:48 ` Michal Hocko
2012-12-13 2:51 ` Jianguo Wu
2012-12-13 2:51 ` Jianguo Wu
2012-12-13 2:51 ` Jianguo Wu
2012-12-13 2:51 ` Jianguo Wu
2012-12-13 5:12 ` Simon Jeons [this message]
2012-12-13 5:12 ` Simon Jeons
2012-12-13 5:12 ` Simon Jeons
2012-12-12 11:23 ` Michal Hocko
[not found] ` <20121212101917.GD32081-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-12-12 10:44 ` Xishi Qiu
2012-12-12 10:19 ` Michal Hocko
2012-12-12 17:05 ` Aneesh Kumar K.V
2012-12-12 17:05 ` Aneesh Kumar K.V
2012-12-12 17:05 ` Aneesh Kumar K.V
2012-12-12 17:05 ` Aneesh Kumar K.V
[not found] ` <8738zb9p59.fsf-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2012-12-13 2:57 ` Jianguo Wu
2012-12-13 2:57 ` Jianguo Wu
2012-12-13 2:57 ` Jianguo Wu
2012-12-13 2:57 ` Jianguo Wu
-- strict thread matches above, loose matches on Subject: below --
2012-12-12 8:25 Jianguo Wu
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=1355375534.1567.1.camel@kernel.cn.ibm.com \
--to=simon.jeons-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=aneesh.kumar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=dhillf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=guohanjun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
--cc=jiang.liu-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=liuj97-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=mhocko-AlSwsSmVLrQ@public.gmane.org \
--cc=qiuxishi-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=wujianguo-hv44wF8Li93QT0dZR+AlfA@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.