Hello, Vladmir. On Mon, Nov 09, 2015 at 09:28:40PM +0300, Vladimir Davydov wrote: > > I am _all_ for this semantic I am just not sure what to do with the > > legacy kmem controller. Can we change its semantic? If we cannot do that > > I think we can. If somebody reports a "bug" caused by this change, i.e. > basically notices that something that used to be accounted is not any > longer, it will be trivial to fix by adding __GFP_ACCOUNT where > appropriate. If it is not, e.g. if accounting of objects of a particular > type leads to intense false-sharing, we would end up disabling > accounting for it anyway. I agree too, if anything is meaningfully broken by the flip, it just indicates that the whitelist needs to be expanded; however, I wonder whether this would be done better at slab level rather than per allocation site. A class of objects which can consume noticeable amount of memory which can be attributed to userland is likely to be on its own slab already or separating it out to its own slab is likely to be a good idea. Marking those slabs as kmemcg accounted seems better suited to the semantics - it's always about classes of objects - and less error-prone than marking individual allocation sites. This also reduces the number of slabs to worry about and more importantly makes it clear which slabs need to be replicated for kmemcg accounting from the beginning and the slab part of implementation can be far simpler / more static. Thanks. -- tejun -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>