From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CD621355F2D for ; Mon, 16 Mar 2026 23:37:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773704238; cv=none; b=ggyKMCLh+QbNF0osyXDoiHjUMVWEsiKLErw6vZhXgs6KgelY2YutGIhh8CQR9JH0jSm3uEZ15UN0lNqH+cQdZyu4OJY42oXsc0k1EujSswQSPuS4lEj5YzrxiUxi3MCDoIVVle7+X++imgsIDAMUisOa+5cG0mw1ElHhPIRkpzA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773704238; c=relaxed/simple; bh=2DmUkIQk68nUHosP/saZetuyTBWym4GTB8xne8YydJ0=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=tKH+N3Xa7nsn2gt81mMXo//WjNf/ZIDKqFKnxnEMk9ojdFZ2Lmb/otR6mdOC2nPXLMvDNy0Lv+cBvV9iE8bHTBpJuu7j9VhaAMlUPz6RN2RdJRWDh3swdlC4cSeh5x1GbqVxkNm8uuBFqZOhLLwjlTfgXMbBnbl0RW/g801TFAM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=QPC5WxpA; arc=none smtp.client-ip=209.85.128.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="QPC5WxpA" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-485345e1013so1322405e9.1 for ; Mon, 16 Mar 2026 16:37:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773704235; x=1774309035; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=FrJSvnP5t2ZAkb3zCRgf6mgahxyGJGt35l4bNQI7QjY=; b=QPC5WxpABMCAeZi6z60g8BZHDoFHTdbDEMC5sJa1WQXmjRCtM7qyq1BN3aLbPQrknC l1JpxGID+JiHi0+D8Eo3kaW7kskN56iB3hw4sSVwcb21I5MJm4pm32zKJs15qqp4L21u nnQfljhQ27BTYWgKwQE2nxFLv61CZ3mkm/+5jIXnrPhihFBG6xfnJYijzGDNfY2RsQ5/ oA/ud4M333RvrCvS/BprY4etcc4XsZdKYFfI+xkKrzwq9Dw+nH9TtyokxzNwlIXPMItP 9fQXC7jZtjHgpskaUBFTZqqxDBQX76FAbyL7lE/nbtlKrRbnKhkg3Vve9tI8fS8qhoCq nQ2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773704235; x=1774309035; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=FrJSvnP5t2ZAkb3zCRgf6mgahxyGJGt35l4bNQI7QjY=; b=iaavzvQPUWRxEZbvBj8JjP47I3w9OxfvsqNEGhhr4qBAZgyx3pckvkk/qV2bfMoQis 32sJOkFGTOr+u7lB+vIweFB/yH7fS7VzZjqa8m33NBatQL4Lr0cVlbJMlV1D7w4sD7X7 Xqza11Rf4Pkmu3QgU0K3y0jUUDhjv1eaZpg/XXOiDLdEnzvbx5XXggSmG0cQ0fk6vSlf tjsd/8MEbkpsJ3S5CHQv6ksCJ6bxgiEQ28hpT2zDylAVEj8yMtwWS5Cfe2qyDfOVpQX3 PBARnpIp/ATX6DRNY/cc2cejj0vQFtjysz7O8GK1v28mplr70Z17ZimOtk8zpEpUbBW2 l3BA== X-Forwarded-Encrypted: i=1; AJvYcCXNouhNJnY8eKEzHbZSUkmymHl1dRUuRtrGcMPilemvgPefnQsRQVD91H1CtOE1mjzxJvF+PM0Rtg==@vger.kernel.org X-Gm-Message-State: AOJu0YyzZizjMmUAcQr+HQY5L5UjXFLuaISxRJA1WDqVtr52BJ2C/oHb DLZcorqsY28qfQUxJRuyd92FAIDRekxiHdnS5A/K45fDGn4x6COy8Ysp X-Gm-Gg: ATEYQzwepAfEImm0pkcCs7l1scCjrQYhShaotpNurCqgd2EZsGif5nUKVTKGBAvCD6D IsSBp5H/3peVzBFPaislg+Sl9Su+Y+S1+b9z4Fk2sQp3KV0n4NZts6XiY4ewa+0T5SH8AE+isH0 ZAx5m7J4ioPEk4u1TiFwUF/k0PkYFFjhdiviNYxvJBb6xGfX6+NqOULZgKS1nuGmyjxS2qCDFGh 4cWByYoVwqSzNiuUsryUzjQy9EDjsrhyuWOE2D+XrC85eiB4629caO/ttvMVkadW5A+LtnR4x4E hA6P8EULuKp2Zxol44lzFDVMfxy5mTgI5+/FOpnxUKLA9Ez+aHLZxgi9CrYCVBjY7LsKA4kYTgI TAUkK7JLxbDgqCeV1x0OoAOONI7YaeyHZBzGfgGe7vozdBeNqJsCiWYAk6aA+cpFaEhqTnvYgEy 5eZNHJWQweKMikvSs7kqt6FkcT+LSum/ETLPh2qy5/UZauvYmGzurV15hXTUW15MbOqNwuxDa8n x8= X-Received: by 2002:a05:600c:17ca:b0:485:343b:38d with SMTP id 5b1f17b1804b1-4856eaac647mr13270265e9.5.1773704234827; Mon, 16 Mar 2026 16:37:14 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43b42e680ddsm14706435f8f.13.2026.03.16.16.37.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Mar 2026 16:37:14 -0700 (PDT) Date: Mon, 16 Mar 2026 23:37:12 +0000 From: David Laight To: Ankur Arora Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org, bpf@vger.kernel.org, arnd@arndb.de, catalin.marinas@arm.com, will@kernel.org, peterz@infradead.org, mark.rutland@arm.com, harisokn@amazon.com, cl@gentwo.org, ast@kernel.org, rafael@kernel.org, daniel.lezcano@linaro.org, memxor@gmail.com, zhenglifeng1@huawei.com, xueshuai@linux.alibaba.com, rdunlap@infradead.org, joao.m.martins@oracle.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com Subject: Re: [PATCH v10 00/12] barrier: Add smp_cond_load_{relaxed,acquire}_timeout() Message-ID: <20260316233712.7cbfac27@pumpkin> In-Reply-To: <874imftol4.fsf@oracle.com> References: <20260316013651.3225328-1-ankur.a.arora@oracle.com> <20260315184925.b6f93386e918ca79614843e3@linux-foundation.org> <874imftol4.fsf@oracle.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-pm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 16 Mar 2026 15:08:07 -0700 Ankur Arora wrote: ... > However, as David Laight pointed out in this thread > (https://lore.kernel.org/lkml/20260214113122.70627a8b@pumpkin/) > that this would be fine so long as the polling is on memory, but would > need some work to handle MMIO. I'm not sure the current code works with MMIO on arm64. I was looking at the osq_lock() code, it uses smp_cond_load() with 'expr' being 'VAL || need_resched()' expecting to get woken by the IPI associated with the preemption being requested. But the arm64 code relies on 'wfe' being woken when the memory write 'breaks' the 'ldx' for the monitored location. That will only work for cached addresses. For osq_lock(), while an IPI will wake it up, there is also a small timing window where the IPI can happen before the ldx and so not actually wake up it. This is true whenever 'expr' is non-trivial. On arm64 I think you could use explicit sev and wfe - but that will wake all 'sleeping' cpu; and you may not want the 'thundering herd'. David