From: Waiman Long <longman@redhat.com>
To: Tejun Heo <tj@kernel.org>, Yosry Ahmed <yosryahmed@google.com>
Cc: Michal Hocko <mhocko@suse.com>,
Shakeel Butt <shakeelb@google.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Andrew Morton <akpm@linux-foundation.org>,
Muchun Song <muchun.song@linux.dev>,
cgroups@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: memcg: provide accurate stats for userspace reads
Date: Tue, 15 Aug 2023 11:44:42 -0400 [thread overview]
Message-ID: <54e8c38d-c805-2666-b559-ce785ba24b67@redhat.com> (raw)
In-Reply-To: <ZNrITZVTf2EILRJq@slm.duckdns.org>
On 8/14/23 20:35, Tejun Heo wrote:
> Hello,
>
> On Mon, Aug 14, 2023 at 05:28:22PM -0700, Yosry Ahmed wrote:
>>> So, the original design used mutex for synchronize flushing with the idea
>>> being that updates are high freq but reads are low freq and can be
>>> relatively slow. Using rstats for mm internal operations changed this
>>> assumption quite a bit and we ended up switching that mutex with a lock.
>> Naive question, do mutexes handle thundering herd problems better than
>> spinlocks? I would assume so but I am not sure.
> I don't know. We can ask Waiman if that becomes a problem.
We had essentially solved the thundering herd problems for both
spinlocks and mutexes. Both types of lock waiters will spin in their own
cachelines (in the OSP wait queue in the case of mutex) except one that
is at the head of the queue. So there should be minimal cacheline
bouncing. One should certainly uses mutexes in sleep-able context or
when the critical section is long.
Cheers,
Longman
next prev parent reply other threads:[~2023-08-15 15:46 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-09 4:58 [PATCH] mm: memcg: provide accurate stats for userspace reads Yosry Ahmed
2023-08-09 8:51 ` Michal Hocko
2023-08-09 12:31 ` Yosry Ahmed
2023-08-09 12:58 ` Michal Hocko
2023-08-09 13:13 ` Yosry Ahmed
2023-08-09 13:31 ` Michal Hocko
2023-08-09 18:33 ` Yosry Ahmed
2023-08-11 12:21 ` Michal Hocko
2023-08-11 19:02 ` Yosry Ahmed
2023-08-11 19:25 ` Michal Hocko
2023-08-11 20:39 ` Yosry Ahmed
2023-08-12 2:08 ` Shakeel Butt
2023-08-12 2:11 ` Yosry Ahmed
2023-08-12 2:29 ` Shakeel Butt
2023-08-12 2:35 ` Yosry Ahmed
2023-08-12 2:48 ` Shakeel Butt
2023-08-12 8:35 ` Michal Hocko
2023-08-12 11:04 ` Yosry Ahmed
2023-08-15 0:14 ` Tejun Heo
2023-08-15 0:28 ` Yosry Ahmed
2023-08-15 0:35 ` Tejun Heo
2023-08-15 0:39 ` Yosry Ahmed
2023-08-15 0:47 ` Tejun Heo
2023-08-15 0:50 ` Yosry Ahmed
2023-08-16 0:23 ` Shakeel Butt
2023-08-16 0:29 ` Yosry Ahmed
2023-08-16 1:14 ` Shakeel Butt
2023-08-16 2:19 ` Yosry Ahmed
2023-08-16 17:11 ` Shakeel Butt
2023-08-16 19:08 ` Tejun Heo
2023-08-16 22:35 ` Yosry Ahmed
2023-08-18 21:40 ` Yosry Ahmed
2023-08-21 20:58 ` Yosry Ahmed
2023-08-15 15:44 ` Waiman Long [this message]
2023-08-09 13:17 ` Yosry Ahmed
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=54e8c38d-c805-2666-b559-ce785ba24b67@redhat.com \
--to=longman@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=shakeelb@google.com \
--cc=tj@kernel.org \
--cc=yosryahmed@google.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;
as well as URLs for NNTP newsgroup(s).