> hm, maybe.  But I'm not sure that touch_nmi_watchdog() will hold off a
> soft lockup warning.  Maybe it will.

It should:

124static inline void touch_nmi_watchdog(void)
126 arch_touch_nmi_watchdog();
127 touch_softlockup_watchdog();

> And please let's get the above thoughts into the changlog.


>> >
>> > I'm not sure what to suggest, really.  Your changelog isn't the best:
>> > "Vlastimil Babka reported about a window issue during which when
>> > deferred pages are initialized, and the current version of on-demand
>> > initialization is finished, allocations may fail".  Well...  where is
>> > ths mysterious window?  Without such detail it's hard for others to
>> > suggest alternative approaches.
>> Here is hopefully a better description of the problem:
>> Currently, during boot we preinitialize some number of struct pages to 
>> satisfy all boot allocations. Even if these allocations happen when we 
>> initialize the reset of deferred pages in page_alloc_init_late(). The 
>> problem is that we do not know how much kernel will need, and it also 
>> depends on various options.
>> So, with this work, we are changing this behavior to initialize struct pages 
>> on-demand, only when allocations happen.
>> During boot, when we try to allocate memory, the on-demand struct page 
>> initialization code takes care of it. But, once the deferred pages are 
>> initializing in:
>> page_alloc_init_late()
>>    for_each_node_state(nid, N_MEMORY)
>>       kthread_run(deferred_init_memmap())
>> We cannot use on-demand initialization, as these threads resize pgdat.
>> This whole thing is to take care of this time.
>> My first version of on-demand deferred page initialization would simply fail 
>> to allocate memory during this period of time. But, this new version waits 
>> for threads to finish initializing deferred memory, and successfully perform 
>> the allocation.
>> Because interrupt handler would wait for pgdat resize lock.
> OK, thanks.  Please also add to changelog.

OK, I will send an updated patch, with changelog changes.

Reply via email to