From nobody Wed Mar 22 18:57:15 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Phd500xPjz419tS for ; Wed, 22 Mar 2023 18:57:24 +0000 (UTC) (envelope-from alex@protasenko.com) Received: from mail.bkmks.com (mail.bkmks.com [45.79.157.50]) (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) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Phd4y4dLMz43Vn for ; Wed, 22 Mar 2023 18:57:22 +0000 (UTC) (envelope-from alex@protasenko.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bkmks.com header.s=mail header.b=D6Oatsqx; spf=pass (mx1.freebsd.org: domain of alex@protasenko.com designates 45.79.157.50 as permitted sender) smtp.mailfrom=alex@protasenko.com; dmarc=none Received: from [192.168.2.11] (pool-173-54-194-2.nwrknj.fios.verizon.net [173.54.194.2]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: aprotasenko@bkmks.com) by mail.bkmks.com (Postfix) with ESMTPSA id 4A4738DD414 for ; Wed, 22 Mar 2023 14:57:16 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.bkmks.com 4A4738DD414 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bkmks.com; s=mail; t=1679511436; bh=8JuGJrBE/tBqgCiHhn93uAuo4HH+43KAaqiT2tt+mZY=; h=Date:Subject:To:References:From:In-Reply-To:From; b=D6OatsqxAZ+ldWazXfWJyPdDpH4plqWbosvTX+XZNoIblnF3DjLQ4wXwg5S+VirTL aOqhKhYuQBnmwBcYNyD4g52/hbtVytMoLEuI7bPwpfQKOHRlfvIkMXjC7CeFpt4PQ4 +eGZYZ9tunaOoWAZQO6c3UdRuID5i5K8FsSFuHrg= Message-ID: Date: Wed, 22 Mar 2023 14:57:15 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: Periodic rant about SCHED_ULE Content-Language: en-US To: freebsd-hackers@freebsd.org References: <8173cc7e-e934-dd5c-312a-1dfa886941aa@FreeBSD.org> <8cfdb951-9b1f-ecd3-2291-7a528e1b042c@m5p.com> From: Alex Protasenko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[bkmks.com:s=mail]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[bkmks.com:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:63949, ipnet:45.79.128.0/19, country:SG]; DMARC_NA(0.00)[protasenko.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[alex]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4Phd4y4dLMz43Vn X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N FWIW, to eliminate "stuttering" for interactive use (desktop), changing defaults for either one of these work wonderfully on recent AMD system (AM4 5700G): kern.sched.steal_thresh=1 or kern.eventtimer.timer=HPET My test case is autoscroll in firefox must be butter smooth, no freezes or jerks, and it works. So, maybe its worth tweaking some knobs to optimize particular workload, although how can one expect reproducible results with something like dnetc? On 3/22/23 14:31, Matthias Andree wrote: > Am 22.03.23 um 15:41 schrieb George Mitchell: >> On 3/22/23 06:17, Matthias Andree wrote: >>> Am 21.03.23 um 23:52 schrieb George Mitchell: >>>> Yes, you've all heard it before [... blah blah blah ...] >>> >>> Can you please also give figures how much CPU time has been allotted >>> to dnetc in that respective situations? >>> >> I let the scheduler do the time allocation.  The result is that dnetc >> gobbles whatever time remains available when higher priority processes >> (i.e. every other process on the system) have nothing to do. With >> SCHED_4BSD the resulting idle time is 0 (as reported by top).  I did >> not take note of the idle time when I was doing the SCHED_ULE run. > > You are not answering my question.  I asked how much time did dnetc > use in the time where you were doing your test compile. > > The next question is then where you get the idea that a scheduler must > interpret 20 as "only if idle". Linux has scheduling classes with > "idle" and "best-effort" priority classes, for one. > > Yes, there are reports that FreeBSD is not responsive by default - but > this may make it get overall better throughput at the expense of > responsiveness, because it might be doing fewer context switches.  So > just complaining about a longer buildworld without seeing how much > dnetc did in the same wallclock time period is useless.  Periodic > rant's don't fix this lack of information. > >