On 5/27/25 11:00, Pankaj Raghav (Samsung) wrote: >> I get that callers have to handle failure. But isn't this pretty nasty >> for mm==NULL callers to be *guaranteed* to fail? They'll generate code >> for the success case that will never even run. >> > The idea was to still have dynamic allocation possible even if this > config was disabled. I don't really understand what you are trying to say here. > You are right that if this config is disabled, the callers with NULL mm > struct are guaranteed to fail, but we are not generating extra code > because there are still users who want dynamic allocation. I'm pretty sure you're making the compiler generate unnecessary code. Think of this: if (mm_get_huge_zero_folio(mm) foo(); else bar(); With the static zero page, foo() is always called. But bar() is dead code. The compiler doesn't know that, so it will generate both sides of the if(). If you can get the CONFIG_... option checks into the header, the compiler can figure it out and not even generate the call to bar(). > Do you think it is better to have the code with inside an #ifdef instead > of using the IS_ENABLED primitive? It has nothing to do with an #ifdef versus IS_ENABLED(). It has to do with the compiler having visibility into how mm_get_huge_zero_folio() works enough to optimize its callers.
