On Thu, Oct 19, 2017 at 3:18 AM, Kirill A. Shutemov <kirill@xxxxxxxxxxxxx> wrote: > On Wed, Oct 18, 2017 at 04:17:30PM -0700, Shakeel Butt wrote: >> Recently we have observed high latency in mlock() in our generic >> library and noticed that users have started using tmpfs files even >> without swap and the latency was due to expensive remote LRU cache >> draining. > > Hm. Isn't the point of mlock() to pay price upfront and make execution > smoother after this? > > With this you shift latency onto reclaim (and future memory allocation). > > I'm not sure if it's a win. > It will not shift latency to fast path memory allocation. Reclaim happens on slow path and only reclaim may see more mlocked pages. Please note that the very antagonistics workload i.e. for each mlock on a cpu, the pages being mlocked happen to be on the cache of other cpus, is very hard to trigger. -- 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>
