Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp726443ybh; Tue, 21 Jul 2020 06:33:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwVk3bJFgv4qps7FW1R+x/+eJ2B/yREKnivO07UIBeNctBtt7OO0dRjwQ7asUs4t7giCC68 X-Received: by 2002:a17:906:3291:: with SMTP id 17mr9759745ejw.370.1595338395455; Tue, 21 Jul 2020 06:33:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595338395; cv=none; d=google.com; s=arc-20160816; b=YrMHY9D63wTbiu8iQ07nKL4NUJPLnAKA8aF0eGdRd7Vxx2dD5m81GH2X2zRKKIbCLj stWVuAmjnm/ah3nPSEWaSkyt+5qDT+iQlbNjnNINVz/cN5uRJcsuVFXFjzWyl6tZ5om9 0I3hfTwWiFAtNDjX8ecbx3mW1AnRKmxSAwxrF7jElg4m/d2T+NlbhjOZtEhnIwFbirJj Eykmg3WMTtaRfswjaHNFZe57GBHeh8N1Gkyqf9omTZH0XdMcnE16hETMEKeky7k9iC3u kK3xaZDJBWawCqxVfFdnrr3FNErvs+dRzxSEjRcPnHvH9u38E6J0skhpqv0uH7lY2Z7d r9CA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=EzYfbCrgknq4IgOaS6VgSZcsIAuPW1DVayw57rymXOE=; b=gsdnE1CNzPNa00qIIaIBt9wl/u129CQ/APOrRDuUabkTqXhhsYJ+UghCdcUskI23zg lhg46k3MfQtYRBi7ZaYHC/iIUoKVDnz69U88iyjEey4lOgLggIcGoe8npK92S2F3hCFE kt/WHbpwmflRFk7gC5clqLxRFT5j1lsXBK6H2lYRa7WmWx5/yfGRa3Jya45nbk7xD+Jw 1o+jSdp9/nid6X6IXqmHcg0Ws4AXqJYjacKIX8KnCKXGsqEnTM61IfZiYneFg2SV5ceI k5MGEe57oMSP69ZRbHc6ZCxNuejADNWz2Gg4phUpNZocefIZnKGVCbLJe7E92cN2Wcww csbw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r20si13381260eda.19.2020.07.21.06.32.52; Tue, 21 Jul 2020 06:33:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728188AbgGUNaN (ORCPT + 99 others); Tue, 21 Jul 2020 09:30:13 -0400 Received: from mail.kernel.org ([198.145.29.99]:35070 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726192AbgGUNaN (ORCPT ); Tue, 21 Jul 2020 09:30:13 -0400 Received: from oasis.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 16189206E9; Tue, 21 Jul 2020 13:30:12 +0000 (UTC) Date: Tue, 21 Jul 2020 09:30:10 -0400 From: Steven Rostedt To: peterz@infradead.org Cc: kernel test robot , kbuild-all@lists.01.org, linux-kernel@vger.kernel.org, x86@kernel.org, Ingo Molnar , sfr@canb.auug.org.au Subject: Re: [tip:sched/fifo 44/45] ERROR: modpost: "sched_setscheduler" undefined! Message-ID: <20200721093010.1c8bd787@oasis.local.home> In-Reply-To: <20200721083643.GG119549@hirez.programming.kicks-ass.net> References: <202006192249.AYnVBGCH%lkp@intel.com> <20200709124505.GT597537@hirez.programming.kicks-ass.net> <20200709115818.36a956a4@oasis.local.home> <20200720214918.GM5523@worktop.programming.kicks-ass.net> <20200720181943.7d8efc65@oasis.local.home> <20200721083643.GG119549@hirez.programming.kicks-ass.net> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 21 Jul 2020 10:36:43 +0200 peterz@infradead.org wrote: > > Yeah, that's fine. You don't have any sched_fifo_high() ? > > Thanks! and no. > > I'll go write a Changelog and add it to tip/sched/fifo, so that > hopefully, sfr can stop complaining about this build fail ;-) > > I've even argued we should rename fifo_low() to something else, but > failed to come up with a sensible name. The intended case is for when > you want something above normal but don't particularly care about RT at > all. > > The thing is, once you start adding priorities, even low,med,high, we're > back to where we were. And the whole argument is that the kernel cannot > set priorities in any sensible fashion. Actually, I was wondering about a "sched_fifo_benchmark()" used specifically for internal testing, where you *want* to disrupt the system. Perhaps have it depend on CONFIG_DEBUG to at least scare people away from using it for normal production code. Or make it print a nasty banner like trace_printk() does. That worked pretty well at keeping people from using it ;-) -- Steve