Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Message-ID: <54e8c38d-c805-2666-b559-ce785ba24b67@redhat.com>
Date:   Tue, 15 Aug 2023 11:44:42 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.7.1
Subject: Re: [PATCH] mm: memcg: provide accurate stats for userspace reads
Content-Language: en-US
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
References: <CAJD7tkbF1tNi8v0W4Mnqs0rzpRBshOFepxFTa1SiSvmBEBUEvw@mail.gmail.com>
 <CALvZod55S3XeK-MquTq0mDuipq8j0vFymQeX_XnPb_HuPK+oGQ@mail.gmail.com>
 <CAJD7tkYZxjAHrodVDK=wmz-sULJrq2VhC_5ecRP7T-KiaOcTuw@mail.gmail.com>
 <CALvZod46Cz_=5UgiyAKM+VgKyk=KJCqDqXu91=9uHy7-2wk53g@mail.gmail.com>
 <CAJD7tkY-ezyYebvcs=8Z_zrw2UVW8jf2WvP1G8tu2rT=2sMnAA@mail.gmail.com>
 <CALvZod5fH9xu_+6x85K38f63GfKGWD1LqtD2R4d09xmDtLB7ew@mail.gmail.com>
 <ZNdEaw2nktq1NfmH@dhcp22.suse.cz>
 <CAJD7tkaFHgc3eN1K1wYsQFWMLu4+Frf9DJ-5HOja2nC20Es9Dw@mail.gmail.com>
 <ZNrDWqfjXtAYhnvT@slm.duckdns.org>
 <CAJD7tkYBFz-gZ2QsHxUMT=t0KNXs66S-zzMPebadHx9zaG0Q3w@mail.gmail.com>
 <ZNrITZVTf2EILRJq@slm.duckdns.org>
From:   Waiman Long <longman@redhat.com>
In-Reply-To: <ZNrITZVTf2EILRJq@slm.duckdns.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


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