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 B4BECD59D90 for ; Tue, 26 Nov 2024 10:28:16 +0000 (UTC) Received: from picard.linux.it (localhost [IPv6:::1]) by picard.linux.it (Postfix) with ESMTP id 0CFBE3DB085 for ; Tue, 26 Nov 2024 11:28:15 +0100 (CET) Received: from in-6.smtp.seeweb.it (in-6.smtp.seeweb.it [IPv6:2001:4b78:1:20::6]) (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 1B3C13DB085 for ; Tue, 26 Nov 2024 11:27:59 +0100 (CET) Authentication-Results: in-6.smtp.seeweb.it; spf=pass (sender SPF authorized) smtp.mailfrom=suse.cz (client-ip=2a07:de40:b251:101:10:150:64:2; helo=smtp-out2.suse.de; envelope-from=chrubis@suse.cz; receiver=lists.linux.it) Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2a07:de40:b251:101:10:150:64:2]) (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-6.smtp.seeweb.it (Postfix) with ESMTPS id 5A055140E705 for ; Tue, 26 Nov 2024 11:27:57 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (unknown [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 BC4D41F457; Tue, 26 Nov 2024 10:27:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1732616875; h=from:from:reply-to: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=pxrcB1W3Ha3E4EmPMz+Zf7sq89zK7CQexRa7GPhNwNY=; b=dtygx5JWSp0qbELFcbSOLpiqFs9BDkXdwgXmPR4wNS6viJaJZwDU2DM4lZlSv/DpIgCb7p r6E+1pUNw+R2vA2YpUARWoyxg3o+VgcbHvKlc3NcyN7wB0pzKP18bNObtaCN6hinA0HVue dbyWOOYhRArzlRZ2X7Mv5GZCpPSoARg= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1732616875; h=from:from:reply-to: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=pxrcB1W3Ha3E4EmPMz+Zf7sq89zK7CQexRa7GPhNwNY=; b=hLoBmFPmrTC/N1Cd+YTJ4Xv/h5DZCzruyPFwyc9EmvuBkospomU5TvAmEPoqpsYUTS5kY0 MC9/sfpdwVWM83Bg== Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1732616874; h=from:from:reply-to: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=pxrcB1W3Ha3E4EmPMz+Zf7sq89zK7CQexRa7GPhNwNY=; b=np5ZSNGpH1fz+auNtqYa4iq6exjH66WHINCx8sEoj3tPiMSiqvyzvcuj4v1K06wyzaWgpk dLy/4c+QS9/vR6T73MK7DSmMxJIKMhVBju5yGee12bFBK0FsvqGA43L/z1+yNeALH6UAOV fAllHwMywrANIgyTfgtwx/avNUpBX7o= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1732616874; h=from:from:reply-to: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=pxrcB1W3Ha3E4EmPMz+Zf7sq89zK7CQexRa7GPhNwNY=; b=52JAxvSpLa1SJWWbLjBDPIC3eutO4CTLRtSj3fBUhiovD3EmdMk0ypEoDHFD63qK3+dy1J KjZdM/N1gBewkMCg== 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 A691D139AA; Tue, 26 Nov 2024 10:27:54 +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 4Wc1KKqiRWffJQAAD6G6ig (envelope-from ); Tue, 26 Nov 2024 10:27:54 +0000 Date: Tue, 26 Nov 2024 11:28:05 +0100 From: Cyril Hrubis To: Li Wang Message-ID: References: <20241126100445.17133-1-liwang@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20241126100445.17133-1-liwang@redhat.com> X-Spamd-Result: default: False [-8.30 / 50.00]; REPLY(-4.00)[]; BAYES_HAM(-3.00)[99.99%]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.20)[-0.999]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FUZZY_BLOCKED(0.00)[rspamd.com]; DKIM_SIGNED(0.00)[suse.cz:s=susede2_rsa,suse.cz:s=susede2_ed25519]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MISSING_XM_UA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.cz:email,imap1.dmz-prg2.suse.org:helo] X-Virus-Scanned: clamav-milter 1.0.3 at in-6.smtp.seeweb.it X-Virus-Status: Clean Subject: Re: [LTP] [RFC PATCH] starvation: set a baseline for maximum runtime 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: Philip Auld , 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! > The commit ec14f4572 ("sched: starvation: Autocallibrate the timeout") > introduced a runtime calibration mechanism to dynamically adjust test > timeouts based on CPU speed. > > While this works well for slower systems like microcontrollers or ARM > boards, it struggles to determine appropriate runtimes for modern CPUs, > especially when debugging kernels with significant overhead. Wouldn't it be better to either skip the test on kernels with debuging confing options on? Or multiply the timeout we got from the callibration when we detect a debugging kernel? The problem is that any number we put there will not be correct in a few years as CPU and RAM speed increase and the test will be effectively doing nothing because the default we put there will cover kernels that are overly slow on a future hardware. -- Cyril Hrubis chrubis@suse.cz -- Mailing list info: https://lists.linux.it/listinfo/ltp