[RFC 00/21] Generic show_mem() - Kernel

This is a discussion on [RFC 00/21] Generic show_mem() - Kernel ; On Wed, Apr 02, 2008 at 10:40:18PM +0200, Johannes Weiner wrote: > Signed-off-by: Johannes Weiner Acked-by: Ralf Baechle Ralf -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 35 of 35

Thread: [RFC 00/21] Generic show_mem()

  1. Re: [RFC 12/22] mips: Use generic show_mem()

    On Wed, Apr 02, 2008 at 10:40:18PM +0200, Johannes Weiner wrote:

    > Signed-off-by: Johannes Weiner


    Acked-by: Ralf Baechle

    Ralf
    --
    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/

  2. Re: [RFC 01/22] Generic show_mem() implementation

    On Wed, Apr 02, 2008 at 10:40:07PM +0200, Johannes Weiner wrote:

    > Signed-off-by: Johannes Weiner


    And also Acked-By: Ralf Baechle .

    Btw, the MIPS part of your patch is not a plain switch from arch to generic
    code as the patch comments seem to imply - the arch version was broken for
    some configs ...

    Ralf
    --
    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/

  3. Re: [RFC 17/22] s390: Use generic show_mem()

    On Thu, Apr 03, 2008 at 03:00:22PM +0200, Johannes Weiner wrote:
    > Hi,
    >
    > Heiko Carstens writes:
    >
    > >> diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
    > >> index 8053245..27b94cb 100644
    > >> --- a/arch/s390/mm/init.c
    > >> +++ b/arch/s390/mm/init.c
    > >> @@ -42,42 +42,6 @@ DEFINE_PER_CPU(struct mmu_gather, mmu_gathers);
    > >> pgd_t swapper_pg_dir[PTRS_PER_PGD] __attribute__((__aligned__(PAGE_SIZE)));
    > >> char empty_zero_page[PAGE_SIZE] __attribute__((__aligned__(PAGE_SIZE)));
    > >>
    > >> - printk("Free swap: %6ldkB\n", nr_swap_pages << (PAGE_SHIFT - 10));
    > >> - printk("%lu pages dirty\n", global_page_state(NR_FILE_DIRTY));
    > >> - printk("%lu pages writeback\n", global_page_state(NR_WRITEBACK));
    > >> - printk("%lu pages mapped\n", global_page_state(NR_FILE_MAPPED));
    > >> - printk("%lu pages slab\n",
    > >> - global_page_state(NR_SLAB_RECLAIMABLE) +
    > >> - global_page_state(NR_SLAB_UNRECLAIMABLE));
    > >> - printk("%lu pages pagetables\n", global_page_state(NR_PAGETABLE));

    > >
    > > These are all missing in the generic implementation.

    >
    > These are all duplicates from show_free_areas().


    In this case ignore my comment
    Btw. your patch regarding the removal of show_free_areas() from
    s390's arch code will be merged during the next merge window.
    --
    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/

  4. Re: [RFC 01/22] Generic show_mem() implementation

    On Thu, Apr 03, 2008 at 04:49:42PM +0200, Johannes Weiner wrote:
    > Hi,
    >
    > Sam Ravnborg writes:
    >
    > >> e.g. we currently have this in arch/s390/Kconfig:
    > >>
    > >> config S390
    > >> def_bool y
    > >> select HAVE_OPROFILE
    > >> select HAVE_KPROBES
    > >> select HAVE_KRETPROBES
    > >>
    > >> just add a select HAVE_GENERIC_SHOWMEM or something like that in the arch
    > >> specific patches.

    > > Seconded.
    > > See Documentation/kbuild/kconfig-language.txt for a few more hints
    > > how to do it.

    >
    > After more thinking about it, wouldn't it be better to have
    > HAVE_ARCH_SHOW_MEM in mm/Kconfig and let archs with their own show_mem()
    > select it? Because there are far more archs that use the generic
    > version than those having their own.


    Positive logic is almost always simpler to grasp.
    And the usual way to do this is to let arch's select what they
    use.
    We do not want to have a situation where in most cases we select
    a generic version but in some oddball case we select to have
    a local version.

    Sam
    --
    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/

  5. Re: [RFC 10/22] m68k: Use generic show_mem()

    On Thu, 3 Apr 2008, Hugh Dickins wrote:
    > On Thu, 3 Apr 2008, Johannes Weiner wrote:
    > > Sorry for the wasted time. These cleanups already took more energy than
    > > they are worth it, I guess... :/

    >
    > Please do persist, I for one appreciate your efforts on this:
    > something I wanted to do years ago but never yet got around to.


    Ack. Don't be disappointed by our comments!

    Gr{oetje,eeting}s,

    Geert

    --
    Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

    In personal conversations with technical people, I call myself a hacker. But
    when I'm talking to journalists I just say "programmer" or something like that.
    -- Linus Torvalds
    --
    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/

  6. Re: [RFC 01/22] Generic show_mem() implementation

    Hi,

    Sam Ravnborg writes:

    > On Thu, Apr 03, 2008 at 04:49:42PM +0200, Johannes Weiner wrote:
    >> Hi,
    >>
    >> Sam Ravnborg writes:
    >>
    >> >> e.g. we currently have this in arch/s390/Kconfig:
    >> >>
    >> >> config S390
    >> >> def_bool y
    >> >> select HAVE_OPROFILE
    >> >> select HAVE_KPROBES
    >> >> select HAVE_KRETPROBES
    >> >>
    >> >> just add a select HAVE_GENERIC_SHOWMEM or something like that in the arch
    >> >> specific patches.
    >> > Seconded.
    >> > See Documentation/kbuild/kconfig-language.txt for a few more hints
    >> > how to do it.

    >>
    >> After more thinking about it, wouldn't it be better to have
    >> HAVE_ARCH_SHOW_MEM in mm/Kconfig and let archs with their own show_mem()
    >> select it? Because there are far more archs that use the generic
    >> version than those having their own.

    >
    > Positive logic is almost always simpler to grasp.
    > And the usual way to do this is to let arch's select what they
    > use.
    > We do not want to have a situation where in most cases we select
    > a generic version but in some oddball case we select to have
    > a local version.


    I can not follow you. Of course the arch selects what they use. But
    they should not _all_ have to be flagged with an extra select. So what
    default-value are you arguing for?

    Hannes
    --
    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/

  7. Re: [RFC 17/22] s390: Use generic show_mem()

    Hi,

    Heiko Carstens writes:

    > On Thu, Apr 03, 2008 at 03:00:22PM +0200, Johannes Weiner wrote:
    >> Hi,
    >>
    >> Heiko Carstens writes:
    >>
    >> >> diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
    >> >> index 8053245..27b94cb 100644
    >> >> --- a/arch/s390/mm/init.c
    >> >> +++ b/arch/s390/mm/init.c
    >> >> @@ -42,42 +42,6 @@ DEFINE_PER_CPU(struct mmu_gather, mmu_gathers);
    >> >> pgd_t swapper_pg_dir[PTRS_PER_PGD] __attribute__((__aligned__(PAGE_SIZE)));
    >> >> char empty_zero_page[PAGE_SIZE] __attribute__((__aligned__(PAGE_SIZE)));
    >> >>
    >> >> - printk("Free swap: %6ldkB\n", nr_swap_pages << (PAGE_SHIFT - 10));
    >> >> - printk("%lu pages dirty\n", global_page_state(NR_FILE_DIRTY));
    >> >> - printk("%lu pages writeback\n", global_page_state(NR_WRITEBACK));
    >> >> - printk("%lu pages mapped\n", global_page_state(NR_FILE_MAPPED));
    >> >> - printk("%lu pages slab\n",
    >> >> - global_page_state(NR_SLAB_RECLAIMABLE) +
    >> >> - global_page_state(NR_SLAB_UNRECLAIMABLE));
    >> >> - printk("%lu pages pagetables\n", global_page_state(NR_PAGETABLE));
    >> >
    >> > These are all missing in the generic implementation.

    >>
    >> These are all duplicates from show_free_areas().

    >
    > In this case ignore my comment
    > Btw. your patch regarding the removal of show_free_areas() from
    > s390's arch code will be merged during the next merge window.


    Okay.

    Do you mean the removal of

    printk("Free swap: %6ldkB\n", nr_swap_pages << (PAGE_SHIFT
    - 10));

    in show_mem()? This was my last patch series about.

    Can I add your Acked-by for _this_ series?

    Thanks,

    Hannes
    --
    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/

  8. Re: [RFC 00/21] Generic show_mem()

    Hi,

    most of the feedback I got now was about information displaying that I
    allegedly have simply dropped. This was only true in one case where I
    missed the quicklist cache, the other droppings were redundant
    information (already displayed in show_free_areas() for example).

    Geert suggested that I should boil down show_mem() first for each arch
    and then unify it but I would prefer unifying it first and listing
    removed redundancy in the changelog of every arch-specific removal. Any
    objections on this?

    Hannes
    --
    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/

  9. Re: [RFC 17/22] s390: Use generic show_mem()

    > > Btw. your patch regarding the removal of show_free_areas() from
    > > s390's arch code will be merged during the next merge window.

    >
    > Okay.
    >
    > Do you mean the removal of
    >
    > printk("Free swap: %6ldkB\n", nr_swap_pages << (PAGE_SHIFT
    > - 10));
    >
    > in show_mem()? This was my last patch series about.


    Yes.

    > Can I add your Acked-by for _this_ series?


    Acked-by: Heiko Carstens
    --
    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/

  10. Re: [RFC 02/22] x86: Use generic show_mem()


    * Johannes Weiner wrote:

    > -config HAVE_ARCH_SHOW_MEM
    > - def_bool y


    > -void show_mem(void)
    > -{


    nice work!

    Acked-by: Ingo Molnar

    Ingo
    --
    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/

  11. Re: [RFC 19/22] um: Use generic show_mem()

    On Wed, Apr 02, 2008 at 10:40:25PM +0200, Johannes Weiner wrote:
    > Signed-off-by: Johannes Weiner


    This looks fine for UML.

    Jeff

    --
    Work email - jdike at linux dot intel dot com
    --
    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/

  12. Re: [RFC 01/22] Generic show_mem() implementation

    On Fri, Apr 04, 2008 at 12:33:42AM +0200, Johannes Weiner wrote:
    > Hi,
    >
    > Sam Ravnborg writes:
    >
    > > On Thu, Apr 03, 2008 at 04:49:42PM +0200, Johannes Weiner wrote:
    > >> Hi,
    > >>
    > >> Sam Ravnborg writes:
    > >>
    > >> >> e.g. we currently have this in arch/s390/Kconfig:
    > >> >>
    > >> >> config S390
    > >> >> def_bool y
    > >> >> select HAVE_OPROFILE
    > >> >> select HAVE_KPROBES
    > >> >> select HAVE_KRETPROBES
    > >> >>
    > >> >> just add a select HAVE_GENERIC_SHOWMEM or something like that in the arch
    > >> >> specific patches.
    > >> > Seconded.
    > >> > See Documentation/kbuild/kconfig-language.txt for a few more hints
    > >> > how to do it.
    > >>
    > >> After more thinking about it, wouldn't it be better to have
    > >> HAVE_ARCH_SHOW_MEM in mm/Kconfig and let archs with their own show_mem()
    > >> select it? Because there are far more archs that use the generic
    > >> version than those having their own.

    > >
    > > Positive logic is almost always simpler to grasp.
    > > And the usual way to do this is to let arch's select what they
    > > use.
    > > We do not want to have a situation where in most cases we select
    > > a generic version but in some oddball case we select to have
    > > a local version.

    >
    > I can not follow you. Of course the arch selects what they use. But
    > they should not _all_ have to be flagged with an extra select. So what
    > default-value are you arguing for?

    The normal pattern is to let arch select the generic implmentation they
    use.
    Just because the majority does use the generic version should not
    make us start to use the inverse logic as in your case.

    So I want all archs that uses the generic show_mem() to
    do an explicit:

    config MYARCH
    select HAVE_GENERIC_SHOWMEM

    Sam
    --
    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/

  13. Re: [RFC 01/22] Generic show_mem() implementation

    Hi Sam,

    Sam Ravnborg writes:

    >> >> After more thinking about it, wouldn't it be better to have
    >> >> HAVE_ARCH_SHOW_MEM in mm/Kconfig and let archs with their own show_mem()
    >> >> select it? Because there are far more archs that use the generic
    >> >> version than those having their own.
    >> >
    >> > Positive logic is almost always simpler to grasp.
    >> > And the usual way to do this is to let arch's select what they
    >> > use.
    >> > We do not want to have a situation where in most cases we select
    >> > a generic version but in some oddball case we select to have
    >> > a local version.

    >>
    >> I can not follow you. Of course the arch selects what they use. But
    >> they should not _all_ have to be flagged with an extra select. So what
    >> default-value are you arguing for?

    > The normal pattern is to let arch select the generic implmentation they
    > use.
    > Just because the majority does use the generic version should not
    > make us start to use the inverse logic as in your case.
    >
    > So I want all archs that uses the generic show_mem() to
    > do an explicit:
    >
    > config MYARCH
    > select HAVE_GENERIC_SHOWMEM
    >
    > Sam


    What is the rationale behind this? It is not a function the arch should
    select at all because it is VM code. The remaining arch-specific
    versions are meant to be removed too.

    It would be like forcing all architectures to select HAVE_GENERIC_PRINTK
    just because one architecture oopses on printk() and needs to replace it
    with its own version.

    Hannes
    --
    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/

  14. Re: [RFC 01/22] Generic show_mem() implementation

    > >> I can not follow you. Of course the arch selects what they use. But
    > >> they should not _all_ have to be flagged with an extra select. So what
    > >> default-value are you arguing for?

    > > The normal pattern is to let arch select the generic implmentation they
    > > use.
    > > Just because the majority does use the generic version should not
    > > make us start to use the inverse logic as in your case.
    > >
    > > So I want all archs that uses the generic show_mem() to
    > > do an explicit:
    > >
    > > config MYARCH
    > > select HAVE_GENERIC_SHOWMEM
    > >
    > > Sam

    >
    > What is the rationale behind this? It is not a function the arch should
    > select at all because it is VM code. The remaining arch-specific
    > versions are meant to be removed too.
    >
    > It would be like forcing all architectures to select HAVE_GENERIC_PRINTK
    > just because one architecture oopses on printk() and needs to replace it
    > with its own version.


    Positive logic and consistency with the CONFIG_HAVE_WHATEVER is the reason.

    But you can solve this problem with no ifdefs and config options at all,
    since you may as well just use __attribute__((weak)) for the generic
    implementation.
    --
    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/

  15. Re: [RFC 01/22] Generic show_mem() implementation

    On Sat, Apr 05, 2008 at 09:51:08AM +0200, Heiko Carstens wrote:

    > But you can solve this problem with no ifdefs and config options at all,
    > since you may as well just use __attribute__((weak)) for the generic
    > implementation.


    Which may result in the version of the function getting linked in but
    staying unreferenced.

    Ralf
    --
    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/

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2