Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1302491 > unrolled thread
| Started by | Michal Hocko <mhocko@kernel.org> |
|---|---|
| First post | 2016-01-06 10:20 +0100 |
| Last post | 2016-01-06 16:10 +0100 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH 1/2] mm, oom: introduce oom reaper Michal Hocko <mhocko@kernel.org> - 2016-01-06 10:20 +0100
Re: [PATCH 1/2] mm, oom: introduce oom reaper Paul Gortmaker <paul.gortmaker@windriver.com> - 2016-01-06 15:30 +0100
Re: [PATCH 1/2] mm, oom: introduce oom reaper Michal Hocko <mhocko@kernel.org> - 2016-01-06 16:10 +0100
| From | Michal Hocko <mhocko@kernel.org> |
|---|---|
| Date | 2016-01-06 10:20 +0100 |
| Subject | Re: [PATCH 1/2] mm, oom: introduce oom reaper |
| Message-ID | <qNSq5-7zw-13@gated-at.bofh.it> |
On Mon 21-12-15 15:38:21, Paul Gortmaker wrote:
[...]
> ...use one of the non-modular initcalls here? I'm trying to clean up most of
> the non-modular uses of modular macros etc. since:
>
> (1) it is easy to accidentally code up an unused module_exit function
> (2) it can be misleading when reading the source, thinking it can be
> modular when the Makefile and/or Kconfig prohibit it
> (3) it requires the include of the module.h header file which in turn
> includes nearly everything else, thus increasing CPP overhead.
>
> I figured no point in sending a follow on patch since this came in via
> the akpm tree into next and that gets rebased/updated regularly.
Sorry for the late reply. I was mostly offline throughout the last 2
weeks last year. Is the following what you would like to see? If yes I
will fold it into the original patch.
Thanks!
---
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 7a9678c50edd..1ece40b94725 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -36,7 +36,7 @@
#include <linux/ftrace.h>
#include <linux/ratelimit.h>
#include <linux/kthread.h>
-#include <linux/module.h>
+#include <linux/init.h>
#include <asm/tlb.h>
#include "internal.h"
@@ -541,7 +541,7 @@ static int __init oom_init(void)
}
return 0;
}
-module_init(oom_init)
+subsys_initcall(oom_init)
#else
static void wake_oom_reaper(struct mm_struct *mm)
{
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Paul Gortmaker <paul.gortmaker@windriver.com> |
|---|---|
| Date | 2016-01-06 15:30 +0100 |
| Message-ID | <qNXg6-2iB-7@gated-at.bofh.it> |
| In reply to | #1302491 |
[Re: [PATCH 1/2] mm, oom: introduce oom reaper] On 06/01/2016 (Wed 10:10) Michal Hocko wrote:
> On Mon 21-12-15 15:38:21, Paul Gortmaker wrote:
> [...]
> > ...use one of the non-modular initcalls here? I'm trying to clean up most of
> > the non-modular uses of modular macros etc. since:
> >
> > (1) it is easy to accidentally code up an unused module_exit function
> > (2) it can be misleading when reading the source, thinking it can be
> > modular when the Makefile and/or Kconfig prohibit it
> > (3) it requires the include of the module.h header file which in turn
> > includes nearly everything else, thus increasing CPP overhead.
> >
> > I figured no point in sending a follow on patch since this came in via
> > the akpm tree into next and that gets rebased/updated regularly.
>
> Sorry for the late reply. I was mostly offline throughout the last 2
> weeks last year. Is the following what you would like to see? If yes I
> will fold it into the original patch.
Yes, that looks fine. Do note that susbsys_initcall is earlier than the
module_init that you were using previously though.
Thanks,
Paul.
--
>
> Thanks!
> ---
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 7a9678c50edd..1ece40b94725 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -36,7 +36,7 @@
> #include <linux/ftrace.h>
> #include <linux/ratelimit.h>
> #include <linux/kthread.h>
> -#include <linux/module.h>
> +#include <linux/init.h>
>
> #include <asm/tlb.h>
> #include "internal.h"
> @@ -541,7 +541,7 @@ static int __init oom_init(void)
> }
> return 0;
> }
> -module_init(oom_init)
> +subsys_initcall(oom_init)
> #else
> static void wake_oom_reaper(struct mm_struct *mm)
> {
> --
> Michal Hocko
> SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Michal Hocko <mhocko@kernel.org> |
|---|---|
| Date | 2016-01-06 16:10 +0100 |
| Message-ID | <qNXSN-2Of-1@gated-at.bofh.it> |
| In reply to | #1302806 |
On Wed 06-01-16 09:26:12, Paul Gortmaker wrote: > [Re: [PATCH 1/2] mm, oom: introduce oom reaper] On 06/01/2016 (Wed 10:10) Michal Hocko wrote: > > > On Mon 21-12-15 15:38:21, Paul Gortmaker wrote: > > [...] > > > ...use one of the non-modular initcalls here? I'm trying to clean up most of > > > the non-modular uses of modular macros etc. since: > > > > > > (1) it is easy to accidentally code up an unused module_exit function > > > (2) it can be misleading when reading the source, thinking it can be > > > modular when the Makefile and/or Kconfig prohibit it > > > (3) it requires the include of the module.h header file which in turn > > > includes nearly everything else, thus increasing CPP overhead. > > > > > > I figured no point in sending a follow on patch since this came in via > > > the akpm tree into next and that gets rebased/updated regularly. > > > > Sorry for the late reply. I was mostly offline throughout the last 2 > > weeks last year. Is the following what you would like to see? If yes I > > will fold it into the original patch. > > Yes, that looks fine. Do note that susbsys_initcall is earlier than the > module_init that you were using previously though. Yes, I have noticed that but quite honestly module_init choice was just "look around and use what others are doing". So there was no particular reason to stick with that order. Thanks for double checking after me! -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web