Message ID | 1536163184-26356-1-git-send-email-rppt@linux.vnet.ibm.com (mailing list archive) |
---|---|
Headers | show |
Series | mm: remove bootmem allocator | expand |
Mike Rapoport <rppt@linux.vnet.ibm.com> 於 2018年9月6日 週四 上午12:04寫道: > > Hi, > > These patches switch early memory managment to use memblock directly > without any bootmem compatibility wrappers. As the result both bootmem and > nobootmem are removed. > > There are still a couple of things to sort out, the most important is the > removal of bootmem usage in MIPS. > > Still, IMHO, the series is in sufficient state to post and get the early > feedback. > > The patches are build-tested with defconfig for most architectures (I > couldn't find a compiler for nds32 and unicore32) and boot-tested on x86 > VM. > Hi Mike, There are nds32 toolchains. https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/x86_64-gcc-8.1.0-nolibc-nds32le-linux.tar.gz https://github.com/vincentzwc/prebuilt-nds32-toolchain/releases/download/20180521/nds32le-linux-glibc-v3-upstream.tar.gz Sorry, we have no qemu yet.
On Wed 05-09-18 18:59:15, Mike Rapoport wrote: [...] > 325 files changed, 846 insertions(+), 2478 deletions(-) > delete mode 100644 include/linux/bootmem.h > delete mode 100644 mm/bootmem.c > delete mode 100644 mm/nobootmem.c This is really impressive! Thanks a lot for working on this. I wish we could simplify the memblock API as well. There are just too many public functions with subtly different semantic and barely any useful documentation. But even this is a great step forward!
On 9/6/18 5:15 AM, Michal Hocko wrote: > On Wed 05-09-18 18:59:15, Mike Rapoport wrote: > [...] >> 325 files changed, 846 insertions(+), 2478 deletions(-) >> delete mode 100644 include/linux/bootmem.h >> delete mode 100644 mm/bootmem.c >> delete mode 100644 mm/nobootmem.c > > This is really impressive! Thanks a lot for working on this. I wish we > could simplify the memblock API as well. There are just too many public > functions with subtly different semantic and barely any useful > documentation. > > But even this is a great step forward! This is a great simplification of boot process. Thank you Mike! I agree, with Michal in the future, once nobootmem kernel stabalizes after this effort, we should start simplifying memblock allocator API: it won't be as big effort as this one, as I think, that can be done in incremental phases, but it will help to make early boot much more stable and uniform across arches. Thank you, Pavel
On Thu, Sep 06, 2018 at 11:15:38AM +0200, Michal Hocko wrote: > On Wed 05-09-18 18:59:15, Mike Rapoport wrote: > [...] > > 325 files changed, 846 insertions(+), 2478 deletions(-) > > delete mode 100644 include/linux/bootmem.h > > delete mode 100644 mm/bootmem.c > > delete mode 100644 mm/nobootmem.c > > This is really impressive! Thanks a lot for working on this. I wish we > could simplify the memblock API as well. There are just too many public > functions with subtly different semantic and barely any useful > documentation. There are also many functions with exactly the same semantic :) Cleaning up the memblock API would be the next step. > But even this is a great step forward! > -- > Michal Hocko > SUSE Labs >
On Thu, Sep 06, 2018 at 01:04:47PM +0000, Pasha Tatashin wrote: > > > On 9/6/18 5:15 AM, Michal Hocko wrote: > > On Wed 05-09-18 18:59:15, Mike Rapoport wrote: > > [...] > >> 325 files changed, 846 insertions(+), 2478 deletions(-) > >> delete mode 100644 include/linux/bootmem.h > >> delete mode 100644 mm/bootmem.c > >> delete mode 100644 mm/nobootmem.c > > > > This is really impressive! Thanks a lot for working on this. I wish we > > could simplify the memblock API as well. There are just too many public > > functions with subtly different semantic and barely any useful > > documentation. > > > > But even this is a great step forward! > > This is a great simplification of boot process. Thank you Mike! > > I agree, with Michal in the future, once nobootmem kernel stabalizes > after this effort, we should start simplifying memblock allocator API: > it won't be as big effort as this one, as I think, that can be done in > incremental phases, but it will help to make early boot much more stable > and uniform across arches. It's not only about the memblock APIs. Every arch has its own way of memory detection and initialization, all this should be revisited at some point. But yes, apart from the memblock APIs update which will be quite disruptive, the arches memory initialization can be updated incrementally. > Thank you, > Pavel
On Thu, Sep 06, 2018 at 10:33:48AM +0800, Greentime Hu wrote: > Mike Rapoport <rppt@linux.vnet.ibm.com> 於 2018年9月6日 週四 上午12:04寫道: > > > > Hi, > > > > These patches switch early memory managment to use memblock directly > > without any bootmem compatibility wrappers. As the result both bootmem and > > nobootmem are removed. > > > > There are still a couple of things to sort out, the most important is the > > removal of bootmem usage in MIPS. > > > > Still, IMHO, the series is in sufficient state to post and get the early > > feedback. > > > > The patches are build-tested with defconfig for most architectures (I > > couldn't find a compiler for nds32 and unicore32) and boot-tested on x86 > > VM. > > > Hi Mike, > > There are nds32 toolchains. > https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/x86_64-gcc-8.1.0-nolibc-nds32le-linux.tar.gz > https://github.com/vincentzwc/prebuilt-nds32-toolchain/releases/download/20180521/nds32le-linux-glibc-v3-upstream.tar.gz Thanks! > Sorry, we have no qemu yet. >