Messages in this thread | | | Date | Mon, 4 May 2020 20:54:33 -0400 | From | Daniel Jordan <> | Subject | Re: [PATCH 5/7] mm: move zone iterator outside of deferred_init_maxorder() |
| |
On Mon, May 04, 2020 at 03:10:46PM -0700, Alexander Duyck wrote: > So we cannot stop in the middle of a max order block. That shouldn't > be possible as part of the issue is that the buddy allocator will > attempt to access the buddy for the page which could cause issues if > it tries to merge the page with one that is not initialized. So if > your code supports that then it is definitely broken. That was one of > the reasons for all of the variable weirdness in > deferred_init_maxorder. I was going through and making certain that > while we were initializing the range we were freeing the pages in > MAX_ORDER aligned blocks and skipping over whatever reserved blocks > were there. Basically it was handling the case where a single > MAX_ORDER block could span multiple ranges. > > On x86 this was all pretty straightforward and I don't believe we > needed the code, but I seem to recall there were some other > architectures that had more complex memory layouts at the time and > that was one of the reasons why I had to be careful to wait until I > had processed the full MAX_ORDER block before I could start freeing > the pages, otherwise it would start triggering memory corruptions.
Yes, thanks, I missed the case where deferred_grow_zone could stop mid-max-order-block.
Maybe it's better to leave deferred_init_maxorder alone and adapt the multithreading to the existing implementation. That'd mean dealing with the pesky opaque index somehow, so deferred_init_mem_pfn_range_in_zone() could be generalized to find it in the thread function based on the start/end range, or it could be maintained as part of the range that padata passes to the thread function.
Or, keep this patch but make sure deferred_grow_zone stops on a max-order-aligned boundary.
| |