From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org,
Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH v2] mm/swap: piggyback lru_add_drain_all() calls
Date: Fri, 4 Oct 2019 16:32:39 +0300 [thread overview]
Message-ID: <c1617cff-847f-4cbf-d314-0382a3e9233d@yandex-team.ru> (raw)
In-Reply-To: <20191004131230.GL9578@dhcp22.suse.cz>
On 04/10/2019 16.12, Michal Hocko wrote:
> On Fri 04-10-19 16:09:22, Konstantin Khlebnikov wrote:
>> This is very slow operation. There is no reason to do it again if somebody
>> else already drained all per-cpu vectors while we waited for lock.
>>
>> Piggyback on drain started and finished while we waited for lock:
>> all pages pended at the time of our enter were drained from vectors.
>>
>> Callers like POSIX_FADV_DONTNEED retry their operations once after
>> draining per-cpu vectors when pages have unexpected references.
>
> This describes why we need to wait for preexisted pages on the pvecs but
> the changelog doesn't say anything about improvements this leads to.
> In other words what kind of workloads benefit from it?
Right now POSIX_FADV_DONTNEED is top user because it have to freeze page
reference when removes it from cache. invalidate_bdev calls it for same reason.
Both are triggered from userspace, so it's easy to generate storm.
mlock/mlockall no longer calls lru_add_drain_all - I've seen here
serious slowdown on older kernel.
There are some less obvious paths in memory migration/CMA/offlining
which shouldn't be called frequently.
>
>> Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
>> ---
>> mm/swap.c | 16 +++++++++++++++-
>> 1 file changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/mm/swap.c b/mm/swap.c
>> index 38c3fa4308e2..5ba948a9d82a 100644
>> --- a/mm/swap.c
>> +++ b/mm/swap.c
>> @@ -708,9 +708,10 @@ static void lru_add_drain_per_cpu(struct work_struct *dummy)
>> */
>> void lru_add_drain_all(void)
>> {
>> + static seqcount_t seqcount = SEQCNT_ZERO(seqcount);
>> static DEFINE_MUTEX(lock);
>> static struct cpumask has_work;
>> - int cpu;
>> + int cpu, seq;
>>
>> /*
>> * Make sure nobody triggers this path before mm_percpu_wq is fully
>> @@ -719,7 +720,19 @@ void lru_add_drain_all(void)
>> if (WARN_ON(!mm_percpu_wq))
>> return;
>>
>> + seq = raw_read_seqcount_latch(&seqcount);
>> +
>> mutex_lock(&lock);
>> +
>> + /*
>> + * Piggyback on drain started and finished while we waited for lock:
>> + * all pages pended at the time of our enter were drained from vectors.
>> + */
>> + if (__read_seqcount_retry(&seqcount, seq))
>> + goto done;
>> +
>> + raw_write_seqcount_latch(&seqcount);
>> +
>> cpumask_clear(&has_work);
>>
>> for_each_online_cpu(cpu) {
>> @@ -740,6 +753,7 @@ void lru_add_drain_all(void)
>> for_each_cpu(cpu, &has_work)
>> flush_work(&per_cpu(lru_add_drain_work, cpu));
>>
>> +done:
>> mutex_unlock(&lock);
>> }
>> #else
>>
>
next prev parent reply other threads:[~2019-10-04 13:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-04 13:09 Konstantin Khlebnikov
2019-10-04 13:12 ` Michal Hocko
2019-10-04 13:32 ` Konstantin Khlebnikov [this message]
2019-10-04 13:39 ` Michal Hocko
2019-10-04 14:06 ` Konstantin Khlebnikov
2019-10-07 12:50 ` Michal Hocko
2019-10-05 19:35 ` Andrew Morton
2019-10-05 20:03 ` Konstantin Khlebnikov
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=c1617cff-847f-4cbf-d314-0382a3e9233d@yandex-team.ru \
--to=khlebnikov@yandex-team.ru \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=willy@infradead.org \
/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