public inbox for linux-riscv@lists.infradead.org
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: guoren <guoren@kernel.org>,
	"Palmer Dabbelt" <palmer@rivosinc.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Andy Lutomirski" <luto@kernel.org>,
	"Conor.Dooley" <conor.dooley@microchip.com>,
	"Heiko Stübner" <heiko@sntech.de>,
	"Jisheng Zhang" <jszhang@kernel.org>,
	"Huacai Chen" <chenhuacai@kernel.org>,
	"Anup Patel" <apatel@ventanamicro.com>,
	"Atish Patra" <atishp@atishpatra.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Björn Töpel" <bjorn@kernel.org>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Will Deacon" <will@kernel.org>,
	"Mike Rapoport" <rppt@kernel.org>,
	"Anup Patel" <anup@brainfault.org>,
	shihua@iscas.ac.cn, jiawei@iscas.ac.cn, liweiwei@iscas.ac.cn,
	luxufan@iscas.ac.cn, chunyu@iscas.ac.cn, tsu.yubo@gmail.com,
	wefu@redhat.com, wangjunqiang@iscas.ac.cn, kito.cheng@sifive.com,
	"Andy Chiu" <andy.chiu@sifive.com>,
	"Vincent Chen" <vincent.chen@sifive.com>,
	"Greentime Hu" <greentime.hu@sifive.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	wuwei2016@iscas.ac.cn, "Jessica Clarke" <jrtc27@jrtc27.com>
Cc: Linux-Arch <linux-arch@vger.kernel.org>,
	linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
	"Guo Ren" <guoren@linux.alibaba.com>
Subject: Re: [RFC PATCH 00/22] riscv: s64ilp32: Running 32-bit Linux kernel on 64-bit supervisor mode
Date: Fri, 19 May 2023 22:20:21 +0200	[thread overview]
Message-ID: <b3689d7f-1a78-46ea-8e1f-48bc080ce993@app.fastmail.com> (raw)
In-Reply-To: <20230518131013.3366406-1-guoren@kernel.org>

On Thu, May 18, 2023, at 15:09, guoren@kernel.org wrote:
> From: Guo Ren <guoren@linux.alibaba.com>
> Why 32-bit Linux?
> =================
> The motivation for using a 32-bit Linux kernel is to reduce memory
> footprint and meet the small capacity of DDR & cache requirement
> (e.g., 64/128MB SIP SoC).
>
> Here are the 32-bit v.s. 64-bit Linux kernel data type comparison
> summary:
> 			32-bit		64-bit
> sizeof(page):		32bytes		64bytes
> sizeof(list_head):	8bytes		16bytes
> sizeof(hlist_head):	8bytes		16bytes
> sizeof(vm_area):	68bytes		136bytes
> ...

> Mem-usage:
> (s32ilp32) # free
>        total   used   free  shared  buff/cache   available
> Mem:  100040   8380  88244      44        3416       88080
>
> (s64lp64)  # free
>        total   used   free  shared  buff/cache   available
> Mem:   91568  11848  75796      44        3924       75952
>
> (s64ilp32) # free
>        total   used   free  shared  buff/cache   available
> Mem:  101952   8528  90004      44        3420       89816
>                      ^^^^^
>
> It's a rough measurement based on the current default config without any
> modification, and 32-bit (s32ilp32, s64ilp32) saved more than 16% memory
> to 64-bit (s64lp64). But s32ilp32 & s64ilp32 have a similar memory
> footprint (about 0.33% difference), meaning s64ilp32 has a big chance to
> replace s32ilp32 on the 64-bit machine.

I've tried to run the same numbers for the debate about running
32-bit vs 64-bit arm kernels in the past, but focused mostly on
slightly larger systems, but I looked mainly at the 512MB case,
as that is the most cost-efficient DDR3 memory configuration
and fairly common.

What I'd like to understand better in your example is where
the 14MB of memory went. I assume this is for 128MB of total
RAM, so we know that 1MB went into additional 'struct page'
objects (32 bytes * 32768 pages). It would be good to know
where the dynamic allocations went and if they are  reclaimable
(e.g. inodes) or non-reclaimable (e.g. kmalloc-128).

For the vmlinux size, is this already a minimal config
that one would run on a board with 128MB of RAM, or a
defconfig that includes a lot of stuff that is only relevant
for other platforms but also grows on 64-bit?

What do you see in /proc/slabinfo, /proc/meminfo/, and
'size vmlinux' for the s64ilp32 and s64lp64 kernels here?

       Arnd

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  parent reply	other threads:[~2023-05-19 20:21 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-18 13:09 [RFC PATCH 00/22] riscv: s64ilp32: Running 32-bit Linux kernel on 64-bit supervisor mode guoren
2023-05-18 13:09 ` [RFC PATCH 01/22] riscv: vdso: Unify vdso32 & compat_vdso into vdso/Makefile guoren
2023-05-18 13:09 ` [RFC PATCH 02/22] riscv: vdso: Remove compat_vdso/ guoren
2023-05-18 13:09 ` [RFC PATCH 03/22] riscv: vdso: Add time-related vDSO common flow for vdso32 guoren
2023-05-18 13:09 ` [RFC PATCH 04/22] clocksource: riscv: s64ilp32: Use __riscv_xlen instead of CONFIG_32BIT guoren
2023-05-18 13:09 ` [RFC PATCH 05/22] riscv: s64ilp32: Introduce xlen_t guoren
2023-05-18 13:09 ` [RFC PATCH 06/22] irqchip: riscv: s64ilp32: Use __riscv_xlen instead of CONFIG_32BIT guoren
2023-05-18 13:09 ` [RFC PATCH 07/22] riscv: s64ilp32: Add sbi support guoren
2023-05-18 13:09 ` [RFC PATCH 08/22] riscv: s64ilp32: Add asid support guoren
2023-05-18 13:10 ` [RFC PATCH 09/22] riscv: s64ilp32: Introduce PTR_L and PTR_S guoren
2023-05-18 13:10 ` [RFC PATCH 10/22] riscv: s64ilp32: Enable user space runtime environment guoren
2023-05-18 13:10 ` [RFC PATCH 11/22] riscv: s64ilp32: Add ebpf jit support guoren
2023-05-18 13:10 ` [RFC PATCH 12/22] riscv: s64ilp32: Add ELF32 support guoren
2023-05-18 13:10 ` [RFC PATCH 13/22] riscv: s64ilp32: Add ARCH RV64 ILP32 compiling framework guoren
2023-05-18 13:10 ` [RFC PATCH 14/22] riscv: s64ilp32: Add MMU_SV39 mode support for 32BIT guoren
2023-05-18 13:10 ` [RFC PATCH 15/22] riscv: s64ilp32: Enable native atomic64 guoren
2023-05-18 13:10 ` [RFC PATCH 16/22] riscv: s64ilp32: Add TImode (128 int) support guoren
2023-05-18 13:10 ` [RFC PATCH 17/22] riscv: s64ilp32: Implement cmpxchg_double guoren
2023-05-18 13:10 ` [RFC PATCH 18/22] riscv: s64ilp32: Disable KVM guoren
2023-05-18 13:10 ` [RFC PATCH 19/22] riscv: Cleanup rv32_defconfig guoren
2023-05-18 13:10 ` [RFC PATCH 20/22] riscv: s64ilp32: Add rv64ilp32_defconfig guoren
2023-05-18 13:10 ` [RFC PATCH 21/22] riscv: s64ilp32: Correct the rv64ilp32 stackframe layout guoren
2023-05-18 13:10 ` [RFC PATCH 22/22] riscv: s64ilp32: Temporary workaround solution to gcc problem guoren
2023-05-18 15:38 ` [RFC PATCH 00/22] riscv: s64ilp32: Running 32-bit Linux kernel on 64-bit supervisor mode Palmer Dabbelt
2023-05-18 18:29   ` Arnd Bergmann
2023-05-19  0:38     ` Paul Walmsley
2023-05-19  8:55       ` Arnd Bergmann
2023-05-19 15:31     ` Guo Ren
2023-05-19 16:53       ` Arnd Bergmann
2023-05-19 17:18         ` Palmer Dabbelt
2023-05-20  1:43         ` Guo Ren
2023-05-19  0:14   ` Paul Walmsley
2023-05-21 12:37     ` Guo Ren
2023-05-19 20:20 ` Arnd Bergmann [this message]
2023-05-20  2:53   ` Guo Ren
2023-05-20 10:13     ` Arnd Bergmann
2023-05-20 15:57       ` Guo Ren

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=b3689d7f-1a78-46ea-8e1f-48bc080ce993@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=andy.chiu@sifive.com \
    --cc=anup@brainfault.org \
    --cc=apatel@ventanamicro.com \
    --cc=atishp@atishpatra.org \
    --cc=bjorn@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=chenhuacai@kernel.org \
    --cc=chunyu@iscas.ac.cn \
    --cc=conor.dooley@microchip.com \
    --cc=corbet@lwn.net \
    --cc=greentime.hu@sifive.com \
    --cc=guoren@kernel.org \
    --cc=guoren@linux.alibaba.com \
    --cc=heiko@sntech.de \
    --cc=jiawei@iscas.ac.cn \
    --cc=jrtc27@jrtc27.com \
    --cc=jszhang@kernel.org \
    --cc=kito.cheng@sifive.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=liweiwei@iscas.ac.cn \
    --cc=luto@kernel.org \
    --cc=luxufan@iscas.ac.cn \
    --cc=mark.rutland@arm.com \
    --cc=palmer@rivosinc.com \
    --cc=paul.walmsley@sifive.com \
    --cc=peterz@infradead.org \
    --cc=rppt@kernel.org \
    --cc=shihua@iscas.ac.cn \
    --cc=tglx@linutronix.de \
    --cc=tsu.yubo@gmail.com \
    --cc=vincent.chen@sifive.com \
    --cc=wangjunqiang@iscas.ac.cn \
    --cc=wefu@redhat.com \
    --cc=will@kernel.org \
    --cc=wuwei2016@iscas.ac.cn \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox