On Wed, Apr 24, 2024 at 04:15:30PM +0300, Mike Rapoport wrote: >On Mon, Apr 22, 2024 at 02:55:00AM +0000, Wei Yang wrote: >> On Mon, Apr 15, 2024 at 06:17:56PM +0300, Mike Rapoport wrote: >> >On Sun, Apr 14, 2024 at 12:45:26AM +0000, Wei Yang wrote: >> >> Current memblock_add_range() does the insertion with two round >> >> iteration. >> >> >> >> First round does the calculation of new region required, and second >> >> round does the actual insertion. Between them, if current max can't meet >> >> new region requirement, it is expanded. >> >> >> >> The worst case is: >> >> >> >> 1. cnt == max >> >> 2. new range overlaps all existing region >> >> >> >> This means the final cnt should be (2 * max + 1). Since we always double >> >> the array size, this means we only need to double the array twice at the >> >> worst case, which is fairly rare. For other cases, only once array >> >> double is enough. >> >> >> >> Let's double the array immediately when there is no room for new region. >> >> This simplify the code a little. >> > >> >Very similar patch was posted a while ago: >> >https://lore.kernel.org/all/20221025070943.363578-1-yajun.deng@xxxxxxxxx >> > >> >and it caused boot regression: >> >https://lore.kernel.org/linux-mm/Y2oLYB7Tu7J91tVm@xxxxxxxxxxxxx >> > >> >> Got the reason for the error. >> >> When we add range to reserved and need double array, following call happends: >> >> memblock_add_range() >> idx <- where we want to insert new range >> memblock_double_array() >> find available range for new regions >> memblock_reserve() available range >> memblock_insert_region() at idx >> >> The error case happens when find available range below what we want to add, >> the idx may change after memblock_reserve(). >> >> The following change looks could fix it. > >I don't think the micro-optimization of the second loop in >memblock_add_range() worth the churn and potential bugs. > Sure, would drop this one. -- Wei Yang Help you, Help me
