From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5F833313E00 for ; Tue, 30 Jun 2026 21:58:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782856726; cv=none; b=OYl1FfaIcW1z4NvBJtRupL/bYM53M+bojFI0Wq26sPQ0ljdtQQiODtf6pjwYTHOatSf+ga0/8fADZdmnP3b0GkIaUmIXrB6WzaQM+UvayaQSrABzCBcsuGgen1iq9sbyNscCLEjeG68GlY4d1czQJWJYBsi+b7rWoHbyVV3/ZNg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782856726; c=relaxed/simple; bh=pIA06d6RWeJhKSc3E7zOkhvNaqyUsTuEFjFFoLPce94=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=psT6RCpA86x6Xngg6b7cuv7EU29QvNkbYoD5YbUtjHikW9lW3xlKpGo4qJB6n1aYv0KVmArqbo9AtMzWWGzM7RMdJ08wzGvdJCFsSbAuUh01zuDaGQF3/ST+VJHd7PzzX4IDaoOlTxI4NO+hqAWNKIBn3vu1LCy7fQZP/YpwQW0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Tr2iUe97; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=Fv4M+t8M; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Tr2iUe97"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="Fv4M+t8M" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782856724; 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: in-reply-to:in-reply-to:references:references; bh=z3TpDHKeSg3hCaDbNSxrROf4Ku8OcMO3gdNHwndIgX4=; b=Tr2iUe97KElbUl+5vA1yS+vWYIrAr4nDtry9hzVj8LmexgJvUnCh3aMSym8yEVg+YwEg/g rooUz/hyxFQhwJ7TyYODboODD1BjSmST29AP7qaUDUmQExPFFTP2DtxLYSicgbJTvneTN3 GPvW+J7blhMZoOeyp4TZxD95JxoSrjk= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-194-2oS_Plz5NDyc0pUrPCTvMQ-1; Tue, 30 Jun 2026 17:58:43 -0400 X-MC-Unique: 2oS_Plz5NDyc0pUrPCTvMQ-1 X-Mimecast-MFC-AGG-ID: 2oS_Plz5NDyc0pUrPCTvMQ_1782856722 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-47127ee7e07so1876939f8f.2 for ; Tue, 30 Jun 2026 14:58:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1782856722; x=1783461522; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=z3TpDHKeSg3hCaDbNSxrROf4Ku8OcMO3gdNHwndIgX4=; b=Fv4M+t8MYJQCCkvQ5HYaYSocvX7G4Hj9/DEvqkDgzit6Wem2iCSk8+76OqBdsPPLLv wratLWUU0paYN5MwO/GdhJMhHP6Poj0bfH3ucJZ5UJmNrf1esH03Dw2ll3guCrTdj6/l yfxkQkhcoTQUmatHYGWHUF4XcaMIRcUbfnQxlKRzRf3C0mw7Q22FE/7IjVozeVRZdNOd 8IR2CB9yGVAv4xZ6QqUxmNJ/+1IgNdBlixII8bLDQ2QnHdLb1YwLYfPG9/ALT2Ma+pNo 3A+axq1wtAblyt3GNg4TaE7swcQ/2jCOGNfJA7g1OyZbzwG2oV5uMJEFvbyTpK1Jh9lZ 61dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782856722; x=1783461522; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=z3TpDHKeSg3hCaDbNSxrROf4Ku8OcMO3gdNHwndIgX4=; b=h9PqB/78tJxb7REY23xDBAPN8xC0xuD9eYhjsj883hfhb655Pv0uMbbHgaIuzCP3UV 93Cs3XTYgm303V//7t1yxFAJFaGJhRwFZvo/IkCgWpGg6zwVn6XCa2sAQ9nN5YYHcOAx /R5eC592QnGck/IsOsxL5mpWJ3vJhB26/9Twzk22gqL95vLEo2t2L05h0H34ut5MNWtt lOnqZDqH7QXQO+q9+Kimq6tOl8saZr1F0lqBeJMjvv8TjKfddcfUCx26h0WmWrL/XEiP aetSsk+W4lZ63YrSNkD0JYGixndfSD3yS96v9ejsAQkGJ3S3QeHYdr8WwCa7Yf85j74o 0Ong== X-Gm-Message-State: AOJu0YzUBAr3qLcLq8mStMxGidi0XStoIc/wz3kVVyEXkUVVkBr1anHM DlG8Kvz1sreGiByqEoVMSx4S8W/ULF6KDGUIbHXlvAvMozL2Ce1Lk5RXhrvTZQv2mm+krFQhxrx FzIaI8SLd3dEIKe05T0fAO0+NCQemBqwa5TyCAIFep2mP2SdISqfz/WcmMSaErizjZA== X-Gm-Gg: AfdE7ckzQLq75MPuBBWHJt7rtTWqSF42OH4yeNe1Wg6eFTlwEOOkBo1/wwfFDWSF90t moHwnwc9Ys3QdhCl7kAyv0u6AQy3Q/pwluqGrKqUyl71r+7I6Imim+rwzwAzBTo6cn4VE8IUg85 ADesh57WFwSEBFHSrGA3rSBflYRuFbucFX3lZaj30RhBKY7/wHHSqk39m/wLayHsvuNhKFC3jVa /5HsF9wUQZQNmysRncd1OPFvfQ5zpvKbQJc6NKjfsCAEA8r0l1O0TMGewVDLsS6ufTMDnxz4Iqt f8Tn6BW33g9g+2zCiozLHOIsApnhELJe+wPeLSnRjCGOeMb94Gi0wWKWwH9P0TMX80P3WMS//p+ PE005XkJvK+uQv16Y70sD+YgC1D0DXtXZ X-Received: by 2002:a05:600c:83cd:b0:493:bb23:152a with SMTP id 5b1f17b1804b1-493bda7e355mr34314725e9.34.1782856721669; Tue, 30 Jun 2026 14:58:41 -0700 (PDT) X-Received: by 2002:a05:600c:83cd:b0:493:bb23:152a with SMTP id 5b1f17b1804b1-493bda7e355mr34314205e9.34.1782856721167; Tue, 30 Jun 2026 14:58:41 -0700 (PDT) Received: from redhat.com (IGLD-80-230-85-71.inter.net.il. [80.230.85.71]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-493be4bfdb4sm27279365e9.3.2026.06.30.14.58.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jun 2026 14:58:40 -0700 (PDT) Date: Tue, 30 Jun 2026 17:58:36 -0400 From: "Michael S. Tsirkin" To: "David Hildenbrand (Arm)" Cc: linux-kernel@vger.kernel.org, Miaohe Lin , Naoya Horiguchi , Andrew Morton , Oscar Salvador , Andi Kleen , Hidehiro Kawai , Rik van Riel , Vlastimil Babka , Lorenzo Stoakes , "Liam R. Howlett" , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Christoph Lameter , David Rientjes , Roman Gushchin , Harry Yoo , Hao Li , Kiryl Shutsemau , Byungchul Park , linux-mm@kvack.org, linux-cxl@vger.kernel.org Subject: Re: [PATCH 0/2] mm: memory-failure: fix HWPoison flag race with non-atomic page flag ops Message-ID: <20260630174852-mutt-send-email-mst@kernel.org> References: <0b5f8b4b-d7dc-4b79-9555-a5b36265f3a9@kernel.org> <20260629030657-mutt-send-email-mst@kernel.org> <4f5ba5d6-246c-4430-9737-e8dd8e4c5142@kernel.org> <20260629092856-mutt-send-email-mst@kernel.org> <54c8cbee-9b26-458c-93ba-5aa594f5d1e8@kernel.org> <20260629174225-mutt-send-email-mst@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Jun 30, 2026 at 08:41:08AM +0200, David Hildenbrand (Arm) wrote: > On 6/30/26 08:30, David Hildenbrand (Arm) wrote: > > On 6/29/26 23:50, Michael S. Tsirkin wrote: > >> On Mon, Jun 29, 2026 at 11:22:11PM +0200, David Hildenbrand (Arm) wrote: > >>> [...] > >>> > >>> > >>> Fully agreed. I was hoping RCU was cheaper (I mean, we were once told that RCU > >>> read side locking is essentially for free ... well in some configs :) ) > >>> > >>> The question if we could optimize it reasonably enough ... > >>> > >>> > >>> ... for example, by doing the rcu read lock + unlock around the > >>> > >>> for (i = 1; i < (1 << order); i++) { > >>> > >>> loop on the alloc path. > >> > >> Is this different from what this patch is doing? > > > > Ah, I missed that we batch this already. We could make it include the > > > > page_cpupid_reset_last(page); > > page->flags.f &= ~PAGE_FLAGS_CHECK_AT_PREP; > > > > As well, to reduce from 3 to 1 locks. > > > > So I guess there is potential for optimization. > > > > [...] > > > >> > >>> I concluded, similar to Andi, that stop_machine() is too big of a hammer. > >>> > >>> I wonder if something could be built out of preempt_disable() and sync SMP > >>> calls. hmm :( > >> > >> rcu_lock is basically same as preempt_disable if rcu is non preemptible, > >> no? > > > > Yes. See my other mail, I learned that preempt_disable() should likely just do > > for our use case. So the preemptible RCU case would not matter. > > > > I assume that's as good as it gets. > > > > 1) Use preempt_disable/preempt_enable to protect > > 2) Batch as good as possible in the page allocator > > > > If the overhead is then still noticeable, there is not a lot we can do to handle > > this cleanly I'm afraid. > > FWIW, there seems to be preempt_enable_no_resched() that is a bit more > lightweight. I'm sure there is some downside, but it might be worth a try. > > -- > Cheers, > > David Yay. I did that + dropped the extra lock/unlock and now it's in the noise in my testing. needs much more testing of course. If you want me to post (including addressing your other feedback) let me know. Or look into call_rcu_tasks/call_rcu_tasks_rude which might work without changes in mm. Or if someone else is gonnu work on this, absolutely fine too. -- MST