On 2021/12/15 19:16, Baoquan He wrote: > On 12/15/21 at 11:01am, Catalin Marinas wrote: >> On Wed, Dec 15, 2021 at 11:42:19AM +0800, Baoquan He wrote: >>> On 12/14/21 at 07:24pm, Catalin Marinas wrote: >>>> On Tue, Dec 14, 2021 at 08:07:58PM +0100, Borislav Petkov wrote: >>>>> On Fri, Dec 10, 2021 at 02:55:25PM +0800, Zhen Lei wrote: >>>>>> From: Chen Zhou <chenzhou10@xxxxxxxxxx> >>>>>> >>>>>> The lower bounds of crash kernel reservation and crash kernel low >>>>>> reservation are different, use the consistent value CRASH_ALIGN. >>>>> >>>>> A big WHY is missing here to explain why the lower bound of the >>>>> allocation range needs to be 16M and why was 0 wrong? >>>> >>>> I asked the same here: >>>> >>>> https://lore.kernel.org/r/20210224143547.GB28965@xxxxxxx >>>> >>>> IIRC Baoquan said that there is a 1MB reserved for x86 anyway in the >>>> lower part, so that's equivalent in practice to starting from >>>> CRASH_ALIGN. >>> >>> Yeah, even for i386, there's area reserved by BIOS inside low 1M. >>> Considering the existing alignment CRASH_ALIGN which is 16M, we >>> definitely have no chance to get memory starting from 0. So starting >>> from 16M can skip the useless memblock searching, and make the >>> crashkernel low reservation consisten with crashkernel reservation on >>> allocation code. >> >> That's the x86 assumption. Is it valid for other architectures once the >> code has been made generic in patch 6? It should be ok for arm64, RAM >> tends to start from higher up but other architectures may start using >> this common code. > > Good point. I didn't think of this from generic code side, then let's > keep it as 0. > >> >> If you want to keep the same semantics as before, just leave it as 0. >> It's not that the additional lower bound makes the search slower. > > Agree. OK, I will drop this patch. > > . >
