Dear Joonsoo,
Joonsoo Kim <[email protected]> writes:
> Currently, we store each page's allocation stacktrace on corresponding
> page_ext structure and it requires a lot of memory. This causes the
> problem that memory tight system doesn't work well if page_owner is
> enabled. Moreover, even with this large memory consumption, we cannot get
> full stacktrace because we allocate memory at boot time and just maintain
> 8 stacktrace slots to balance memory consumption. We could increase it to
> more but it would make system unusable or change system behaviour.
[...]
This patch causes my Wandboard Quad [1] not to boot anymore. I don't get
any kernel output, even with earlycon enabled
(earlycon=ec_imx6q,0x02020000). git bisect pointed towards your patch;
reverting the patch causes the system to boot fine again. Config is
available at [2]; none of the defconfigs I tried (defconfig =
multi_v7_defconfig, imx_v6_v7_defconfig) works for me.
Haven't looked into this any further so far; hooking up a JTAG adapter
requires some hardware changes as the JTAG header is unpopulated.
Sascha
PS: Please CC me on replies; I'm not subscribed to any of the lists.
[1] http://www.wandboard.org/index.php/details/wandboard
[2] https://sascha.silbe.org/tmp/config-4.8.4-wandboard-28-00003-g9e9b5d6
--
Softwareentwicklung Sascha Silbe, Niederhofenstraße 5/1, 71229 Leonberg
https://se-silbe.de/
USt-IdNr.: DE281696641
Hello,
Thanks for the report.
On Wed, Oct 26, 2016 at 03:06:05PM +0200, Sascha Silbe wrote:
> Dear Joonsoo,
>
> Joonsoo Kim <[email protected]> writes:
>
> > Currently, we store each page's allocation stacktrace on corresponding
> > page_ext structure and it requires a lot of memory. This causes the
> > problem that memory tight system doesn't work well if page_owner is
> > enabled. Moreover, even with this large memory consumption, we cannot get
> > full stacktrace because we allocate memory at boot time and just maintain
> > 8 stacktrace slots to balance memory consumption. We could increase it to
> > more but it would make system unusable or change system behaviour.
> [...]
>
> This patch causes my Wandboard Quad [1] not to boot anymore. I don't get
> any kernel output, even with earlycon enabled
> (earlycon=ec_imx6q,0x02020000). git bisect pointed towards your patch;
> reverting the patch causes the system to boot fine again. Config is
> available at [2]; none of the defconfigs I tried (defconfig =
> multi_v7_defconfig, imx_v6_v7_defconfig) works for me.
>
> Haven't looked into this any further so far; hooking up a JTAG adapter
> requires some hardware changes as the JTAG header is unpopulated.
>
> Sascha
>
> PS: Please CC me on replies; I'm not subscribed to any of the lists.
>
> [1] http://www.wandboard.org/index.php/details/wandboard
> [2] https://sascha.silbe.org/tmp/config-4.8.4-wandboard-28-00003-g9e9b5d6
> --
> Softwareentwicklung Sascha Silbe, Niederhofenstra?e 5/1, 71229 Leonberg
> https://se-silbe.de/
> USt-IdNr.: DE281696641
I cannot see your config. Link [2] shows "No such file or directory"
Anyway, I find that there is an issue in early boot phase in
!CONFIG_SPARSEMEM. Could you try following one?
(It's an completely untested patch, even I don't try to compile it.)
Thanks.
---------->8---------------
diff --git a/include/linux/page_ext.h b/include/linux/page_ext.h
index 9298c39..db31f58 100644
--- a/include/linux/page_ext.h
+++ b/include/linux/page_ext.h
@@ -47,6 +47,7 @@ struct page_ext {
};
extern void pgdat_page_ext_init(struct pglist_data *pgdat);
+extern void __init invoke_init_callbacks(void);
#ifdef CONFIG_SPARSEMEM
static inline void page_ext_init_flatmem(void)
@@ -57,6 +58,7 @@ static inline void page_ext_init_flatmem(void)
extern void page_ext_init_flatmem(void);
static inline void page_ext_init(void)
{
+ invoke_init_callbacks();
}
#endif
diff --git a/mm/page_ext.c b/mm/page_ext.c
index 121dcff..a405869 100644
--- a/mm/page_ext.c
+++ b/mm/page_ext.c
@@ -91,7 +91,7 @@ static bool __init invoke_need_callbacks(void)
return need;
}
-static void __init invoke_init_callbacks(void)
+void __init invoke_init_callbacks(void)
{
int i;
int entries = ARRAY_SIZE(page_ext_ops);
@@ -190,7 +190,6 @@ void __init page_ext_init_flatmem(void)
goto fail;
}
pr_info("allocated %ld bytes of page_ext\n", total_usage);
- invoke_init_callbacks();
return;
fail:
Dear Joonsoo,
Joonsoo Kim <[email protected]> writes:
> Anyway, I find that there is an issue in early boot phase in
> !CONFIG_SPARSEMEM. Could you try following one?
> (It's an completely untested patch, even I don't try to compile it.)
Finally got JTAG to work just enough to dive into this. Turned out to be
another case of the FDT clashing with the BSS area. Your patch caused
BSS to grow by > 4 MiB so that it now collides with the (old) default
FDT location on this board. There's nothing wrong with your patch, just
the usual black magic of placing initramfs and FDT in RAM on ARM.
Sascha
--
Softwareentwicklung Sascha Silbe, Niederhofenstraße 5/1, 71229 Leonberg
https://se-silbe.de/
USt-IdNr.: DE281696641