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 AEE6AC54EED for ; Mon, 30 Jan 2023 09:00:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235928AbjA3JAj (ORCPT ); Mon, 30 Jan 2023 04:00:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42754 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235820AbjA3JAh (ORCPT ); Mon, 30 Jan 2023 04:00:37 -0500 Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5771027997 for ; Mon, 30 Jan 2023 01:00:35 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id e16so11887633ljn.3 for ; Mon, 30 Jan 2023 01:00:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=o4goC00EkIWkDaKtqyTtWFudz4ow776Co421veWBFv8=; b=qKnRdRbm8dxI2wYdKscZL7nk3i6L07fv+KvkcY2LKUV3CTM15qQAWPDH6FnM5mt0Kq qWx3HTNjo9AQmx+fmI7j699It4/oEHCBzlrxa7cByjMV9M7oWwJprB/BY8OmMD8/wLP/ tZv8mz3q/wtdG3DXDfSoRDHmndegR0ImdoGTa7IBXIh92Ll2PV8GyqZoQ5o8g6gc5We/ kddHCp2vB5SbVXJEcYkjDGZmAZyDI8b00LaRpOt2FAVSaOyq1VZvNRZqZ8HRAO5wI7OE th47rCAB9WoZc0y/CuU62DJw4/1Z54bJnx1tS6ixnhO5fSZ/wW62Weyb76LpGrDt9/fi 2/dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=o4goC00EkIWkDaKtqyTtWFudz4ow776Co421veWBFv8=; b=UrJzmU87TIaUSXTFigMJ+Xmpf5gGumLRZp12WvGLWMmhxSpYLqL45gh6EKOy5LUZkt MfLYeQxTrVjdly72MmttFYARk54U0AJVZlhDj2IdU1ikHSfFeYTsX5pMq362WWuY0SDI 6Xc111k5Vb66c5vwHhYu+/EMJgtCcoSbV3IOSLvm49wPNu/RVqskLgJ1oRI8SRMU2lyL wWejvbllymitI951WO3a+LMa8zmuLfymYDJBt6VnDpRnfDZCfdjKrK65TirgK+Jk0RoL HSdsvcenKcMTemU1CSQwri9ZhTlU934QdMV95jMea4f5jfsFYq9tz9vuRp3pTcaZ38xh /pjw== X-Gm-Message-State: AO0yUKVTqGMOJ8MQtNDEJGzeagyP8l50Fkr+bYunQPPXnY3w28A8lYTY 7SHjup26xTM7rpg3VxFcILwIiceoOXzBj8w5AdQ5F7S3TJCn9do4vBQ= X-Google-Smtp-Source: AK7set+Zb71Wk5u4TfLX15p388KImys4JbPqG9R3g5B6u0SIzNYdGG+M38gtVlxrqfWlktiK7bET4R69oG79Htx+k0M= X-Received: by 2002:a2e:aa14:0:b0:28f:81a2:6eb with SMTP id bf20-20020a2eaa14000000b0028f81a206ebmr1307259ljb.118.1675069233468; Mon, 30 Jan 2023 01:00:33 -0800 (PST) MIME-Version: 1.0 References: <20230126105128.2249938-1-dvyukov@google.com> <20230126154118.2393850-1-dvyukov@google.com> <87o7qlgjce.ffs@tglx> <20230128195641.GA14906@redhat.com> In-Reply-To: <20230128195641.GA14906@redhat.com> From: Dmitry Vyukov Date: Mon, 30 Jan 2023 10:00:20 +0100 Message-ID: Subject: Re: [PATCH v4] posix-timers: Prefer delivery of signals to the current thread To: Oleg Nesterov Cc: Thomas Gleixner , Marco Elver , linux-kernel@vger.kernel.org, "Eric W . Biederman" , Frederic Weisbecker Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 28 Jan 2023 at 20:56, Oleg Nesterov wrote: > > Dmitry, > > I agree with what you said, just one note... > > On 01/27, Dmitry Vyukov wrote: > > > > After this change the test passes quickly (within a second for me). > > yet perhaps it makes sense to slightly change it? It does > > +static void *distribution_thr(void *arg) { > + while (__atomic_load_n(&remain, __ATOMIC_RELAXED)); > + return NULL; > +} > > so distribution_thr() eats CPU even after this thread gets a signal and thus > (in theory) it can "steal" cpu_timer_fire() from other threads unpredictably > long ? How about > > - while (__atomic_load_n(&remain, __ATOMIC_RELAXED)); > + while (__atomic_load_n(&got_signal, __ATOMIC_RELAXED)); > ? But why? IIUC this makes the test even "weaker". As Thomas notes it's already somewhat "weak". And this would make it even "weaker". So if it passes in the current version, I would keep it as is. It makes sense to relax it only if it's known to fail sometimes. But it doesn't fail as far as I know. And the intention is really that the current version must pass -- all threads must get signals even if other threads are running.