On Mon, Jan 14, 2019 at 4:50 PM Mike Rapoport <rppt@xxxxxxxxxxxxx> wrote: > > On Mon, Jan 14, 2019 at 04:33:50PM +0800, Pingfan Liu wrote: > > On Mon, Jan 14, 2019 at 3:51 PM Mike Rapoport <rppt@xxxxxxxxxxxxx> wrote: > > > > > > Hi Pingfan, > > > > > > On Fri, Jan 11, 2019 at 01:12:53PM +0800, Pingfan Liu wrote: > > > > During boot time, there is requirement to tell whether a series of func > > > > call will consume memory or not. For some reason, a temporary memory > > > > resource can be loan to those func through memblock allocator, but at a > > > > check point, all of the loan memory should be turned back. > > > > A typical using style: > > > > -1. find a usable range by memblock_find_in_range(), said, [A,B] > > > > -2. before calling a series of func, memblock_set_current_limit(A,B,true) > > > > -3. call funcs > > > > -4. memblock_find_in_range(A,B,B-A,1), if failed, then some memory is not > > > > turned back. > > > > -5. reset the original limit > > > > > > > > E.g. in the case of hotmovable memory, some acpi routines should be called, > > > > and they are not allowed to own some movable memory. Although at present > > > > these functions do not consume memory, but later, if changed without > > > > awareness, they may do. With the above method, the allocation can be > > > > detected, and pr_warn() to ask people to resolve it. > > > > > > To ensure there were that a sequence of function calls didn't create new > > > memblock allocations you can simply check the number of the reserved > > > regions before and after that sequence. > > > > > Yes, thank you point out it. > > > > > Still, I'm not sure it would be practical to try tracking what code that's called > > > from x86::setup_arch() did memory allocation. > > > Probably a better approach is to verify no memory ended up in the movable > > > areas after their extents are known. > > > > > It is a probability problem whether allocated memory sit on hotmovable > > memory or not. And if warning based on the verification, then it is > > also a probability problem and maybe we will miss it. > > I'm not sure I'm following you here. > > After the hotmovable memory configuration is detected it is possible to > traverse reserved memblock areas and warn if some of them reside in the > hotmovable memory. > Oh, sorry that I did not explain it accurately. Let use say a machine with nodeA/B/C from low to high memory address. With top-down allocation by default, at this point, memory will always be allocated from nodeC. But it depends on machine whether nodeC is hotmovable or not. The verification can pass on a machine with unmovable nodeC , but fails on a machine with movable nodeC. It will be a probability issue. Thanks [...]
