>> >If CMA decide they want to alter mlocked pages in this way, it's sortof >> >ok. While CMA is being used, there are no expectations on the RT >> >behaviour of the system - stalls are expected. In their use cases, CMA >> >failing is far worse than access latency to an mlocked page being >> >variable while CMA is running. >> >> That's strange. CMA caller can't know the altered page is under mlock or not. >> and almost all CMA user is in embedded world. ie RT realm. > > Embedded does not imply realtime constraints. True. but much overwrapped. >> So, I don't think >> CMA and compaction are significantly different. > > CMA is used in cases such as a mobile phone needing to allocate a large > contiguous range of memory for video decoding. Compaction is used by > features such as THP with khugepaged potentially using it frequently on > x86-64 machines. The use cases are different and compaction is used by > THP a lot more than CMA is used by anything. Fair point. usecase frequency is clearly different. > If compaction can move mlocked pages then khugepaged can introduce unexpected > latencies on mlocked anonymous regions of memory. Yes, it can. Then, the problem depend on how much applications assume mlock provide no minor fault. right? My claim was, I suspect such applications certainly exist, but very few. Automatic moving makes 99.9% applications happy. example, modern distro have >1000 utility commands and I suspect _all_ command don't care minor fault. OK, a few high end and hpc applications certainly care it. but is it majority? >> >Compaction on the other hand is during the normal operation of the >> >machine. There are applications that assume that if anonymous memory >> >is mlocked() then access to it is close to zero latency. They are >> >not RT-critical processes (or they would disable THP) but depend on >> >this. Allowing compaction to migrate mlocked() pages will result in bugs >> >being reported by these people. >> > >> >I've received one bug this year about access latency to mlocked() regions but >> >it turned out to be a file-backed region and related to when the write-fault >> >is incurred. The ultimate fix was in the application but we'll get new bug >> >reports if anonymous mlocked pages do not preserve the current guarantees >> >on access latency. >> >> Can you please tell us your opinion about autonuma? > > I think it will have the same problem as THP using compaction. If > mlocked pages can move then there may be unexpected latencies accessing > mlocked anonymous regions. > >> I doubt we can keep such >> mlock guarantee. I think we need to suggest application fix. maybe to introduce >> MADV_UNMOVABLE is good start. it seems to solve autonuma issue too. > > That'll regress existing applications. It would be preferable to me that > it be the other way around to not move mlocked pages unless the user says > it's allowed. My conclusion is different but I don't disagree your point. see above. I know you are right too. -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>