On Mon, Jun 08, 2026 at 04:28:48PM +0200, David Hildenbrand (Arm) wrote: > On 6/8/26 16:08, Michael S. Tsirkin wrote: > > On Mon, Jun 08, 2026 at 02:46:34PM +0200, David Hildenbrand (Arm) wrote: > >> On 6/8/26 14:25, Lorenzo Stoakes wrote: > >>> > >>> Do not put comments about specific expected races like this in the commit > >>> message but not in the code. Subtleties need to be called out. > >>> > >>> The commit message also doesn't at all explain why PG_zeroed doesn't > >>> suffice here. > >>> > >>> > >>> I really don't understand why you have a 'zeroed' folio flag but need to > >>> also have new API calls to detect that? > >>> > >>> They're also HORRIBLY named. Zeroed as in what? Zero page? Huge zero page? > >>> Memory zeroed by kernel? Pages that userland happen to have zeroed? Or > >>> host > >>> VM zeroed? > >>> > >>> Each are cases we address individually and relate to folios. > >>> > >>> You absolutely fail to clarify _which one_ you mean, and provide > >>> absolutely > >>> no documentation and add an exported mm API with no description. > >>> > >>> This is just I think not something we want to add? Especially on something > >>> so fundamental? > >> > >> I raised previously that providing a folio helper is odd, and that I > >> suggested > >> that we defer this change. > > > > Sadly it's a dependency actually - without it memcg failures would cause > > repeated re-zeroing where previously it failed without zeroing. > > Oh, you mean that we succeeded allocating (+zeroing) but failed to charge? > > I don't immediately see that to be a real problem?
Yes exactly. I don't really know if any real applications live close enough to memcg edge that repeatedly wasting cycles zeroing pages then discarding that information will be noticeable. I should be able to write a test to show the difference, if that's the question. So just writing code in a way that we are not regressing them seemed cleaner to me. But I'm not a maintainer so hey. Just so we are clear. -- MST
