On Wed, Feb 28, 2024 at 10:28 AM Vlastimil Babka <vbabka@xxxxxxx> wrote: > > On 2/28/24 18:50, Suren Baghdasaryan wrote: > > On Wed, Feb 28, 2024 at 12:47 AM Vlastimil Babka <vbabka@xxxxxxx> wrote: > > > >> > >> Now this might be rare enough that it's not worth fixing if that would be > >> too complicated, just FYI. > > > > Yeah. We can fix this by subtracting the "bytes" counter of the "head" > > page for all free_the_page(page + (1 << order), order) calls we do > > inside __free_pages(). But we can't simply use pgalloc_tag_sub() > > because the "calls" counter will get over-decremented (we allocated > > all of these pages with one call). I'll need to introduce a new > > pgalloc_tag_sub_bytes() API and use it here. I feel it's too targeted > > of a solution but OTOH this is a special situation, so maybe it's > > acceptable. WDYT? > > Hmm I think there's a problem that once you fail put_page_testzero() and > detect you need to do this, the page might be already gone or reallocated so > you can't get to the tag for decrementing bytes. You'd have to get it > upfront (I guess for "head && order > 0" cases) just in case it happens. > Maybe it's not worth the trouble for such a rare case. Yes, that hit me when I tried to implement it but there is a simple solution around that. I can obtain alloc_tag before doing put_page_testzero() and then decrement bytes counter directly as needed. Not sure if it is a rare enough case that we can ignore it but if the fix is simple enough then might as well do it? > > >> > >> > >> > Every time > >> > one of these pages are freed that codetag's "bytes" and "calls" > >> > counters will be decremented. I think accounting will work correctly > >> > irrespective of where these pages are freed, in __free_pages() or by > >> > put_page(). > >> > > >> > > -- > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@xxxxxxxxxxx. >
