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 picard.linux.it (picard.linux.it [213.254.12.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B514CCA1002 for ; Thu, 4 Sep 2025 11:43:07 +0000 (UTC) Received: from picard.linux.it (localhost [IPv6:::1]) by picard.linux.it (Postfix) with ESMTP id ED9D53CD44F for ; Thu, 4 Sep 2025 13:43:05 +0200 (CEST) Received: from in-7.smtp.seeweb.it (in-7.smtp.seeweb.it [217.194.8.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1)) (No client certificate requested) by picard.linux.it (Postfix) with ESMTPS id 211113CCEBC for ; Thu, 4 Sep 2025 13:42:49 +0200 (CEST) Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by in-7.smtp.seeweb.it (Postfix) with ESMTPS id B6E6B20024B for ; Thu, 4 Sep 2025 13:42:48 +0200 (CEST) Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 33F575D4A5; Thu, 4 Sep 2025 11:42:48 +0000 (UTC) Authentication-Results: smtp-out2.suse.de; none Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 212B013AA0; Thu, 4 Sep 2025 11:42:48 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id RgvIBzh7uWj7RQAAD6G6ig (envelope-from ); Thu, 04 Sep 2025 11:42:48 +0000 Date: Thu, 4 Sep 2025 13:42:41 +0200 From: Cyril Hrubis To: Petr Vorel Message-ID: References: <20250904102609.133359-1-liwang@redhat.com> <20250904110018.GA56668@pevik> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20250904110018.GA56668@pevik> X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Server: rspamd1.dmz-prg2.suse.org X-Spamd-Result: default: False [-4.00 / 50.00]; REPLY(-4.00)[] X-Rspamd-Queue-Id: 33F575D4A5 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Action: no action X-Virus-Scanned: clamav-milter 1.0.7 at in-7.smtp.seeweb.it X-Virus-Status: Clean Subject: Re: [LTP] [PATCH v2] sched_football: synchronize with kickoff flag to reduce skew X-BeenThere: ltp@lists.linux.it X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Test Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ltp@lists.linux.it Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ltp-bounces+ltp=archiver.kernel.org@lists.linux.it Sender: "ltp" Hi! > > static void do_setup(void) > > { > > + if (!tst_check_preempt_rt()) > > + tst_brk(TCONF, "Test requires real-time kernel"); > > I understood Cyril is really suggesting to keep it [1]. I would also vote to > keep it (we still have some time to see if it got fixed before release). > > I know we had this discussion in the past (some of your colleague suggesting it > should not be run on non-RT kernel), so I'm not pushing for it. I stil do not understand reasons for disabling the test. The POSIX realtime schedulling classes have to work properly regardless of the kernel flavor. Why should we turn the test off on non-rt kernel then? It may make sense to prolong the settling period for non-rt something as: ... if (tst_check_preempt_rt() settling_period = 20000; else settling_period = 200000; ... usleep(settling_period); ... In order to make sure non-rt scheduller has enough time to shuffle the processes around the available CPUs. But that should be the only difference. -- Cyril Hrubis chrubis@suse.cz -- Mailing list info: https://lists.linux.it/listinfo/ltp