From: Shakeel Butt <shakeelb@google.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Vlastimil Babka <vbabka@suse.cz>, Michal Hocko <mhocko@suse.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Minchan Kim <minchan@kernel.org>,
Yisheng Xie <xieyisheng1@huawei.com>,
Ingo Molnar <mingo@kernel.org>, Greg Thelen <gthelen@google.com>,
Hugh Dickins <hughd@google.com>, Linux MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: mlock: remove lru_add_drain_all()
Date: Thu, 19 Oct 2017 12:19:20 -0700 [thread overview]
Message-ID: <CALvZod53p3P_cM9bZVtjgQ34Y5+d+bF__sOpgUfofMS7n8Ugog@mail.gmail.com> (raw)
In-Reply-To: <20171019101832.xli25kizn3y55pbq@node.shutemov.name>
On Thu, Oct 19, 2017 at 3:18 AM, Kirill A. Shutemov
<kirill@shutemov.name> 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@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-10-19 19:19 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-18 23:17 Shakeel Butt
2017-10-19 3:18 ` Balbir Singh
2017-10-19 20:12 ` Shakeel Butt
2017-10-19 6:24 ` Anshuman Khandual
2017-10-19 19:19 ` Shakeel Butt
2017-10-19 10:18 ` Kirill A. Shutemov
2017-10-19 19:19 ` Shakeel Butt [this message]
2017-10-19 12:32 ` Michal Hocko
2017-10-19 19:19 ` Shakeel Butt
2017-10-19 19:35 ` Michal Hocko
2017-10-19 19:46 ` Shakeel Butt
2017-10-19 20:13 ` Michal Hocko
2017-10-19 20:14 ` Shakeel Butt
2017-10-19 20:53 ` Michal Hocko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALvZod53p3P_cM9bZVtjgQ34Y5+d+bF__sOpgUfofMS7n8Ugog@mail.gmail.com \
--to=shakeelb@google.com \
--cc=akpm@linux-foundation.org \
--cc=gthelen@google.com \
--cc=hughd@google.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=minchan@kernel.org \
--cc=mingo@kernel.org \
--cc=vbabka@suse.cz \
--cc=xieyisheng1@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox