From: Michal Hocko <mhocko@kernel.org>
To: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
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 15:12:30 +0200 [thread overview]
Message-ID: <20191004131230.GL9578@dhcp22.suse.cz> (raw)
In-Reply-To: <157019456205.3142.3369423180908482020.stgit@buzz>
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?
> 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
>
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2019-10-04 13:12 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 [this message]
2019-10-04 13:32 ` Konstantin Khlebnikov
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=20191004131230.GL9578@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=khlebnikov@yandex-team.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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