On Sat, Apr 11, 2020 at 08:45:35AM +0000, Chintan Pandya wrote:
> > > +#else
> > > +void clear_huge_page(struct page *page,
> > > + unsigned long addr_hint, unsigned int
> > > +pages_per_huge_page) {
> > > + void *addr;
> > > +
> > > + addr = page_address(page);
> > > + memset(addr, 0, pages_per_huge_page*PAGE_SIZE); } #endif
> >
> > This seems like a very simplistic solution to the problem, and I am worried
> > something like this would introduce latency issues when pages_per_huge_page
> > gets to be large. It might make more sense to just wrap the process_huge_page
> > call in the original clear_huge_page and then add this code block as an #else
> > case. That way you avoid potentially stalling a system for extended periods of
> > time if you start trying to clear 1G pages with the function.
> >
> > One interesting data point would be to see what the cost is for breaking this up
> > into a loop where you only process some fixed number of pages and running it
> > with cond_resched() so you can avoid introducing latency spikes.
>
> As per the patch above, it's not using kmap_atomic() and hence preemption & page_fault
> are not disabled. Do we still need to explicitly call cond_resched() in this case?
> #justAsking
Didn't see this answered on the list, but the answer is yes because the kernel
may not have CONFIG_PREEMPTION enabled.
