On Tue, 2019-10-01 at 14:35 +0200, Vlastimil Babka wrote: > On 10/1/19 2:32 PM, Vlastimil Babka wrote: > > On 10/1/19 2:26 PM, Qian Cai wrote: > > > On Tue, 2019-10-01 at 14:51 +0300, Kirill A. Shutemov wrote: > > > > On Tue, Oct 01, 2019 at 10:07:44AM +0200, Vlastimil Babka wrote: > > > > > On 10/1/19 1:49 AM, Qian Cai wrote: > > > > > > > > DEBUG_PAGEALLOC is much more intrusive debug option. Not all architectures > > > > support it in an efficient way. Some require hibernation. > > > > > > > > I don't see a reason to tie these two option together. > > > > > > Make sense. How about page_owner=on will have page_owner_free=on by default? > > > That way we don't need the extra parameter. > > > > > > There were others that didn't want that overhead (memory+cpu) always. So the > > last version is as flexible as we can get, IMHO, before approaching bikeshed > > territory. It's just another parameter. > > Or suggest how to replace page_owner=on with something else (page_owner=full?) > and I can change that. But I don't want to implement a variant where we store only > the freeing stack, though. I don't know why you think it is a variant. It sounds to me it is a natural extension that belongs to page_owner=on that it could always store freeing stack to help with debugging. Then, it could make implementation easier without all those different combinations you mentioned in the patch description that could confuse anyone. If someone complains about the overhead introduced to the existing page_owner=on users, then I think we should have some number to prove that say how much overhead there by storing freeing stack in page_owner=on, 10%, 50%?
