Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED

2024-01-15 Thread Vitaly Wool
On Fri, Jan 12, 2024 at 8:31 PM Yosry Ahmed  wrote:
>
> The z3fold compressed pages allocator is not widely used, most users use
> zsmalloc. The only disadvantage of zsmalloc in comparison is the
> dependency on MMU, and zbud is a more common option for !MMU as it was
> the default zswap allocator for a long time.
>
> In hopes of having a single compressed pages allocator at some point,
> and following in the footsteps of SLAB, deprecate z3fold. Rename the
> user-visible option so that users with CONFIG_Z3FOLD=y get a new prompt
> with explanation during make oldconfig. Remove CONFIG_Z3FOLD=y from
> defconfigs.

I believe that having a single compressed pages allocator is a false goal.

> Existing users, if any, should voice their objections. Otherwise, we can
> remove z3fold in a few releases.

At this point I NACK this patch. We're about to submit an allocator
which is clearly better that z3fold and is faster that zsmalloc in
most cases and that submission will mark z3fold as deprecated. But for
now this move is premature.

Best,
Vitaly

> Signed-off-by: Yosry Ahmed 
> ---
> I have limited understanding of Kconfigs. I modelled this after commit
> eb07c4f39c3e ("mm/slab: rename CONFIG_SLAB to CONFIG_SLAB_DEPRECATED"),
> but one difference is that CONFIG_Z3FOLD is a tristate. I made
> CONFIG_Z3FOLD_DEPRECATED a boolean config, and CONFIG_Z3FOLD default y
> so that it is on by default if CONFIG_Z3FOLD_DEPRECATED is selected. I
> am not sure if that's the correct way to do this.
>
> ---
>  arch/loongarch/configs/loongson3_defconfig |  1 -
>  arch/powerpc/configs/ppc64_defconfig   |  1 -
>  mm/Kconfig | 13 +++--
>  3 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/arch/loongarch/configs/loongson3_defconfig 
> b/arch/loongarch/configs/loongson3_defconfig
> index 33795e4a5bd63..89b66b6c6a1d5 100644
> --- a/arch/loongarch/configs/loongson3_defconfig
> +++ b/arch/loongarch/configs/loongson3_defconfig
> @@ -85,7 +85,6 @@ CONFIG_ZPOOL=y
>  CONFIG_ZSWAP=y
>  CONFIG_ZSWAP_COMPRESSOR_DEFAULT_ZSTD=y
>  CONFIG_ZBUD=y
> -CONFIG_Z3FOLD=y
>  CONFIG_ZSMALLOC=m
>  # CONFIG_COMPAT_BRK is not set
>  CONFIG_MEMORY_HOTPLUG=y
> diff --git a/arch/powerpc/configs/ppc64_defconfig 
> b/arch/powerpc/configs/ppc64_defconfig
> index 544a65fda77bc..d39284489aa26 100644
> --- a/arch/powerpc/configs/ppc64_defconfig
> +++ b/arch/powerpc/configs/ppc64_defconfig
> @@ -81,7 +81,6 @@ CONFIG_MODULE_SIG_SHA512=y
>  CONFIG_PARTITION_ADVANCED=y
>  CONFIG_BINFMT_MISC=m
>  CONFIG_ZSWAP=y
> -CONFIG_Z3FOLD=y
>  CONFIG_ZSMALLOC=y
>  # CONFIG_SLAB_MERGE_DEFAULT is not set
>  CONFIG_SLAB_FREELIST_RANDOM=y
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 1902cfe4cc4f5..bc6cc97c08349 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -193,15 +193,24 @@ config ZBUD
>   deterministic reclaim properties that make it preferable to a higher
>   density approach when reclaim will be used.
>
> -config Z3FOLD
> -   tristate "3:1 compression allocator (z3fold)"
> +config Z3FOLD_DEPRECATED
> +   bool "3:1 compression allocator (z3fold) (DEPRECATED)"
> depends on ZSWAP
> help
> + Deprecated and scheduled for removal in a few cycles. If you have
> + a good reason for using Z3FOLD rather than ZSMALLOC or ZBUD, please
> + contact linux...@kvack.org and the zswap maintainers.
> +
>   A special purpose allocator for storing compressed pages.
>   It is designed to store up to three compressed pages per physical
>   page. It is a ZBUD derivative so the simplicity and determinism are
>   still there.
>
> +config Z3FOLD
> +   tristate
> +   default y
> +   depends on Z3FOLD_DEPRECATED
> +
>  config ZSMALLOC
> tristate
> prompt "N:1 compression allocator (zsmalloc)" if ZSWAP
> --
> 2.43.0.275.g3460e3d667-goog
>


Re: [PATCH 1/2] powerpc: export ppc_tb_freq so that modules can reference it

2010-09-18 Thread Vitaly Wool
On Sat, Sep 18, 2010 at 5:34 PM, Kumar Gala kumar.g...@freescale.com wrote:

 I don't think either of these should be EXPORT_SYMBOL_GPL.  Why shouldn't a 
 binary module be allowed to know these frequencies?  My view is why preclude 
 anyone from using this how they want.  If they want to live in the gray area 
 so be it.  Who am I to say they shouldn't have that choice.

W00t, binary modules again... No, please. No binary modules in kernelspace.

Thanks,
   Vitaly
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] [POWEPC] crashdump: do not fail on null pointer dereferencing

2010-05-11 Thread Vitaly Wool
Hi,

 diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
 index 6f4613d..341d8af 100644
 --- a/arch/powerpc/kernel/crash.c
 +++ b/arch/powerpc/kernel/crash.c
 @@ -375,6 +375,9 @@ void default_machine_crash_shutdown(struct pt_regs *regs)
        for_each_irq(i) {
                struct irq_desc *desc = irq_to_desc(i);

 +               if (!desc || !desc-chip || !desc-chip-eoi)
 +                       continue;
 +

Kinda unlikely that desc can be NULL here :)

~Vitaly
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: Linux patches for XIP on MPC8xx?

2010-03-24 Thread Vitaly Wool
Hi,

 There were very few tests done with later kernel versions, and in all
 practical system configurations we tested we found that XIP did not
 give real benefits. Usually execution from flash was slower than when
 running from RAM, and even booting a (inevitably uncompressed) kernel
 from flash is typically slower than loading a compressed image to RUM
 and booting from there.

at some point we were testing some hybrid approaches for XIP and that
gave some nice results.

First of all, the kernel should not necessarily be uncompressed.
Because .data and friend sections are copied to RAM anyway, you can
compress them.

Besides, we had the weird XIP kernel version with only run-once code
run as XIP (like .initdata), copying the rest of kernel to RAM in the
background while initializing things, and it was really fast and
didn't produce performance penalty on the further execution.

 So except for some highly specialized applications (you may also call
 these exotic configurations) XIP for the Linux kernel does not make
 much sense to me.

Well, I'd put it this way: plain XIP usage is obsolete in the most
cases, but the idea is still viable if you apply it right :)

Thanks,
   Vitaly
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev