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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 65729C433F5 for ; Thu, 23 Dec 2021 16:02:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 867226B0073; Thu, 23 Dec 2021 11:02:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 815F96B0074; Thu, 23 Dec 2021 11:02:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6B6C26B0075; Thu, 23 Dec 2021 11:02:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0202.hostedemail.com [216.40.44.202]) by kanga.kvack.org (Postfix) with ESMTP id 5B83E6B0073 for ; Thu, 23 Dec 2021 11:02:17 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 1EC4C8A9CE for ; Thu, 23 Dec 2021 16:02:17 +0000 (UTC) X-FDA: 78949525914.22.F6E341F Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf07.hostedemail.com (Postfix) with ESMTP id 41407400AD for ; Thu, 23 Dec 2021 16:01:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1640275301; 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=+x9d3eMLDnOzojapyWMBgtJ2Do86y7jIA1pTdOWS/vg=; b=P+KvMwA/B3dCv+FNlo6jBIEqBD38v7yyhXe3xVhFGoBLITHZaU2WJXkHernNuN5KZCvRxE m/BoGBq7kHCYZa4K9yLm15vn+FFhJA95WNKIjidctR6ZHkHnqaQ7LDKAZX+mFCvO/qoC5l wi3uWPKBYxzhdFXbn6xqITw5GoLUgvM= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-88-M2QYBhyQOoy4_zi7ZmOFvg-1; Thu, 23 Dec 2021 11:01:40 -0500 X-MC-Unique: M2QYBhyQOoy4_zi7ZmOFvg-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9007161240; Thu, 23 Dec 2021 16:01:38 +0000 (UTC) Received: from [10.22.17.249] (unknown [10.22.17.249]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8A3BBADDD; Thu, 23 Dec 2021 16:01:37 +0000 (UTC) Message-ID: <407858bc-a5ad-c17c-3f8b-ac65dc912990@redhat.com> Date: Thu, 23 Dec 2021 11:01:37 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: [RFC PATCH 1/3] mm/memcg: Protect per-CPU counter by disabling preemption on PREEMPT_RT Content-Language: en-US To: Sebastian Andrzej Siewior Cc: cgroups@vger.kernel.org, linux-mm@kvack.org, Johannes Weiner , Michal Hocko , Vladimir Davydov , Andrew Morton , Thomas Gleixner , Peter Zijlstra References: <20211222114111.2206248-1-bigeasy@linutronix.de> <20211222114111.2206248-2-bigeasy@linutronix.de> From: Waiman Long In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="P+KvMwA/"; spf=none (imf07.hostedemail.com: domain of longman@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=longman@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Queue-Id: 41407400AD X-Stat-Signature: e1dwwde4cw96q4z5zh89nxhropxk53de X-Rspamd-Server: rspam04 X-HE-Tag: 1640275301-912797 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 12/23/21 02:34, Sebastian Andrzej Siewior wrote: > On 2021-12-22 21:31:36 [-0500], Waiman Long wrote: >> On 12/22/21 06:41, Sebastian Andrzej Siewior wrote: >>> The per-CPU counter are modified with the non-atomic modifier. The >>> consistency is ensure by disabling interrupts for the update. >>> This breaks on PREEMPT_RT because some sections additionally >>> acquire a spinlock_t lock (which becomes sleeping and must not be >>> acquired with disabled interrupts). Another problem is that >>> mem_cgroup_swapout() expects to be invoked with disabled interrupts >>> because the caller has to acquire a spinlock_t which is acquired with >>> disabled interrupts. Since spinlock_t never disables interrupts on >>> PREEMPT_RT the interrupts are never disabled at this point. >>> >>> The code is never called from in_irq() context on PREEMPT_RT therefore >> How do you guarantee that these percpu update functions won't be called in >> in_irq() context for PREEMPT_RT? Do you think we should add a >> WARN_ON_ONCE(in_irq()) just to be sure? > There are no invocations to the memory allocator (neither malloc() nor > free()) on RT and the memory allocator itself (SLUB and the > page-allocator so both) has sleeping locks. That means invocations > in_atomic() are bad. All interrupt handler are force-threaded. Those > which are not (like timer, per-CPU interrupts or those which explicitly > asked not to be force threaded) are limited in their doing as they can't > invoke anything that has a sleeping lock. Lockdep or > CONFIG_DEBUG_ATOMIC_SLEEP will yell here. > The other counter are protected the same way, see > c68ed7945701a ("mm/vmstat: protect per cpu variables with preempt disable on RT") Thanks for the explanation as I am less familiar with other PREEMPT_RT specific changes. Cheers, Longman From mboxrd@z Thu Jan 1 00:00:00 1970 From: Waiman Long Subject: Re: [RFC PATCH 1/3] mm/memcg: Protect per-CPU counter by disabling preemption on PREEMPT_RT Date: Thu, 23 Dec 2021 11:01:37 -0500 Message-ID: <407858bc-a5ad-c17c-3f8b-ac65dc912990@redhat.com> References: <20211222114111.2206248-1-bigeasy@linutronix.de> <20211222114111.2206248-2-bigeasy@linutronix.de> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1640275303; 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=+x9d3eMLDnOzojapyWMBgtJ2Do86y7jIA1pTdOWS/vg=; b=gNA589Y55py55zeCMG2Dv8LaDMuTdCcwZhAQ7E2TFA34tePQn/zRwC8IDitf+CWuDg8OyP QTeuja6evGmxs+peJjRZBlzMffgHaoSXIAtqnjbIczBN0yDNUk0AvQXiME5tgtlFOZa1Fm ohJJx1Wz8KRM5S3Th+eKktWeUIAtc/Y= Content-Language: en-US In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Sebastian Andrzej Siewior Cc: cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Johannes Weiner , Michal Hocko , Vladimir Davydov , Andrew Morton , Thomas Gleixner , Peter Zijlstra On 12/23/21 02:34, Sebastian Andrzej Siewior wrote: > On 2021-12-22 21:31:36 [-0500], Waiman Long wrote: >> On 12/22/21 06:41, Sebastian Andrzej Siewior wrote: >>> The per-CPU counter are modified with the non-atomic modifier. The >>> consistency is ensure by disabling interrupts for the update. >>> This breaks on PREEMPT_RT because some sections additionally >>> acquire a spinlock_t lock (which becomes sleeping and must not be >>> acquired with disabled interrupts). Another problem is that >>> mem_cgroup_swapout() expects to be invoked with disabled interrupts >>> because the caller has to acquire a spinlock_t which is acquired with >>> disabled interrupts. Since spinlock_t never disables interrupts on >>> PREEMPT_RT the interrupts are never disabled at this point. >>> >>> The code is never called from in_irq() context on PREEMPT_RT therefore >> How do you guarantee that these percpu update functions won't be called in >> in_irq() context for PREEMPT_RT? Do you think we should add a >> WARN_ON_ONCE(in_irq()) just to be sure? > There are no invocations to the memory allocator (neither malloc() nor > free()) on RT and the memory allocator itself (SLUB and the > page-allocator so both) has sleeping locks. That means invocations > in_atomic() are bad. All interrupt handler are force-threaded. Those > which are not (like timer, per-CPU interrupts or those which explicitly > asked not to be force threaded) are limited in their doing as they can't > invoke anything that has a sleeping lock. Lockdep or > CONFIG_DEBUG_ATOMIC_SLEEP will yell here. > The other counter are protected the same way, see > c68ed7945701a ("mm/vmstat: protect per cpu variables with preempt disable on RT") Thanks for the explanation as I am less familiar with other PREEMPT_RT specific changes. Cheers, Longman