From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BBA05C41513 for ; Tue, 15 Aug 2023 15:46:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238271AbjHOPqA (ORCPT ); Tue, 15 Aug 2023 11:46:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44700 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238283AbjHOPpp (ORCPT ); Tue, 15 Aug 2023 11:45:45 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B6C89E61 for ; Tue, 15 Aug 2023 08:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1692114300; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TawkjbN36L2tJSa3Vtp7sv1FkX0qieEa0khYy9fqi68=; b=GzVNpKWauBuwo5xlmYTiOTpaE75kyZKcq3hD2XfUMvFrqBbINHmFucLu/gZpeWVuB30XI1 5SAxRiSc8jU2IQHDEubTF65lIyKQfO80lX56Xw6+4jnWsqdcyl13TVvJYsVfdk8Ul3pySy i9gYzaGTq1QAceiu1zZlrjyQcxIZrdA= Received: from mimecast-mx02.redhat.com (66.187.233.73 [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-390-Tdg2iIrqNFaYgkrb_S-NTw-1; Tue, 15 Aug 2023 11:44:53 -0400 X-MC-Unique: Tdg2iIrqNFaYgkrb_S-NTw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8DC1529DD987; Tue, 15 Aug 2023 15:44:43 +0000 (UTC) Received: from [10.22.18.67] (unknown [10.22.18.67]) by smtp.corp.redhat.com (Postfix) with ESMTP id E6AAEC15BAD; Tue, 15 Aug 2023 15:44:42 +0000 (UTC) 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 , Yosry Ahmed Cc: Michal Hocko , Shakeel Butt , Johannes Weiner , Roman Gushchin , Andrew Morton , Muchun Song , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: From: Waiman Long In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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