From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (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 D867429BDB5 for ; Tue, 17 Mar 2026 09:17:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773739032; cv=none; b=rimge+W8ASjehYZ/ebBsQ8G0KCHZqmFMTCfoiXqOJq4YCjXVTKOxeShpdcx0GGZwSWzZ2GR0eL8so7e+jfkBvQNynQe2oH3ooPV27h0gRUYsRB3lkTWLnQrElH1aIrQJ8b3Sf886Fhe1ysTt+WMiykf6ZfUjRz6QqdOaeYLQBsY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773739032; c=relaxed/simple; bh=dtTlCI41aozPTprXi9NLFL5XTO3EzPdQWfOwuMTboPk=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=oiBLPWsJe8gHkk6opHc/6XcAukgVYLzBheS0r7UcE+eB5fHNSDQYxdsrrfcAmnIvNMRWgYXzCTrg2gAWJIKR+tLQepR5BhIxiJvMdZoPBLiVC/WnNHeF77Ez4J0O4bOD9EcBQ3J04JgENODbeKLYHSIThB3idBJ4Dx2xmKiNv5I= 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=fG2q/vtu; arc=none smtp.client-ip=209.85.128.49 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="fG2q/vtu" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-48538c5956bso5316465e9.0 for ; Tue, 17 Mar 2026 02:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773739028; x=1774343828; 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=6M98aQTjWa8T+7ERPNFsSGl3sVEntJ3KUS4g5D7crqo=; b=fG2q/vtuNbzuklQBCk2lkDj0WVbhIZEBgPNCSNifvBQFx+XepfFhvU3S6Hw+SMsd+T ZvPleBcQ8goyWn52ywY8+Xn4wnaQ0aPqoJQbwSyChKxm30GW1zEAkFPRDUsSRjKemlIC CiwrE3HNmyCiEOvqwjXybVFxYyDPkCP81Fpc6dM/mYhDUgRx8lmFyo3X+3F52mSro0/2 9QoivY6AcT1W6GtEugGJcPJHbOZkMH8dlotwx7lO9ZsPn/wh58IK1zRhuKDCcv10uQ+i xswq97GzXF0Pb7+PCRlEoqcD46RDvTQ3vphxeN5U2YMCl1JR/qYquwNwrjj/mDl9TDKw WJ0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773739028; x=1774343828; 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=6M98aQTjWa8T+7ERPNFsSGl3sVEntJ3KUS4g5D7crqo=; b=Tu7K20wE8Ow9yQB73wkURCRkbZEXlefxnyN8lqVL9yrAdqDHXxthW8gqDmjfvJZRxo Mtpg1J7QRtxvYwhT0p3YZJCiDctB29kcrLc8LsJC7PThxuj9gq+p0ebNO1XvCgIOYkMF ia7r65XaMHBH273lRDtLE1CSzwiKg+pvIoNK8C0S/8MI0gr9kLDANoo5gmwQNUcbZqMg zBWcPB2CTlaRDWbpvbtbsW8u3T+ft4kua5TbCrhzyg2+XW+b0DMJNVuJD/ZHowbNtN84 hUjItuXaQco/UfyUhVRbCoiVZS9Ec68sSh5cxTsJ2S0GxYXKrIlzILQ0OvmItbrJeUoW fzNw== X-Forwarded-Encrypted: i=1; AJvYcCWljhSrDmXR+df8/7E00tlIMa4vOrpeQ4kOhQ1GZINo9dzsPk5YDB+QLkZtLdED8nfdBMQUEsKq/vAywNk=@vger.kernel.org X-Gm-Message-State: AOJu0Yz99AQgUEYah2NKKSeGGWBLstuMiY9UxE4Oa0idwOxPIj65099q ldzMcYlArOVio+WcpSA6S9t6HyzR+qCkrkcdoz4sE1g8fONc26JWlkly X-Gm-Gg: ATEYQzxXZyAnz/mxohXSsXiCafL60W4cNWhZR15NUgTeFIzK//vbLT1vDtIFm8qghA0 mUbF7AMWiV3Tuc/oceKdRZRs+JxkMqrfkFb4kWmGCKQnchQ2oezP8xBpivvNTPgBtDAuciZ/E9+ 0WaQ74jrjkQMcN0/eM/xhLKWKoHFGM278gOzaGkb4AEDjvGnEPQJFUfcGCgyDuUqI5HB5MBLL5H gIXSuvI50cH+ktj3VKmkGY+MQ5rFXIXKb3vc7/DSVjc53dkj9j+NwDq6yLgUBfbmb4yXdkuV5hw 8doVBL6rvU2dwRsyPe37IlWTgn/3z2WkK3b5DlPaDQPSl0t2XCIdn0q+fObk4JzKPN/tkJDOz+T 93XgrQE82FrBKg78OYMoKGDboU+X+5Ot2gtdX4g5W/+/nzj7gywgCJvYQC8gLXmEsy2ayTZLbkK x+23s1mQvSvI/QjeZ2Z9ucbMAVWWCHMFoqUuJQMSNtTl5X1BL9kkd6t2ylY674+TvQ X-Received: by 2002:a05:600c:5249:b0:485:38f1:5cec with SMTP id 5b1f17b1804b1-4856eac2b35mr44375555e9.7.1773739027522; Tue, 17 Mar 2026 02:17:07 -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 5b1f17b1804b1-4856ea8fb0dsm99153105e9.3.2026.03.17.02.17.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Mar 2026 02:17:07 -0700 (PDT) Date: Tue, 17 Mar 2026 09:17:05 +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: <20260317091705.5a64fc56@pumpkin> In-Reply-To: <87ms07rlp9.fsf@oracle.com> References: <20260316013651.3225328-1-ankur.a.arora@oracle.com> <20260315184925.b6f93386e918ca79614843e3@linux-foundation.org> <874imftol4.fsf@oracle.com> <20260316233712.7cbfac27@pumpkin> <87ms07rlp9.fsf@oracle.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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-Transfer-Encoding: 7bit On Mon, 16 Mar 2026 23:53:22 -0700 Ankur Arora wrote: > David Laight writes: ... > > 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'. > > Wouldn't we still have the same narrow window where the CPU disregards the IPI? You need a 'sevl' in the interrupt exit path. (Or, more specifically, the ISR needs to exit with the flag set.) Actually I think you need one anyway, if the ISR clears the flag then the existing code will sleep until the following IRQ if an interrupt happens between the ldx and wfe. I've not looked at the ISR exit code. Ignoring the vcu check (which is fairly broken anyway), I think osq_lock() would be ok if the 'osq node' were in the right cache line. I've some patches pending (I need to sort out lots of comments) that reduce the osq_node down to two cpu numbers; 8 bytes but possibly only 4 although that is harder without 16bit atomics. That would work for arm32 (ldx uses a cache-line resolution) but I'm not sure about similar functionality on other cpu. David > > -- > ankur