From nobody Thu May 5 22:34:54 2022 X-Original-To: arch@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 816931AB0525 for ; Thu, 5 May 2022 22:34:56 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KvT683FLvz3s7y; Thu, 5 May 2022 22:34:56 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1651790096; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ifFQmnQ7iIR1pRicAZsQKES80us/Y2BvSxJI0WIJnTo=; b=V1XWmzhhu58Gl6kIa3EAwLwSjksht35SxQUwm/pEgmce5Y9ar4z/3IevjcU96iUgp+HPei lmkFKYAOq02IknNBPMubAy6N4XnaIQLmCEsa/3DWO09Z2/3WeKmT/0L4xUru0N1EYmi5Wg mLiLP9ME8y6yoJerZ+LDKF9ez0gLoKkWjXjOmjYdk1IUcj57JbdAPBid6eYdfQBMvk9Ygd 7CEAQm5OqFW8T5aVoKVdZjDLBbW0PGDoj4sXJcKttb4pCywMp115PGyKTc8xwJ9jMRDTol O9Zo5HaPuNhrWUgmw5FDrTBT1ty7ODuA7/8fdjuqQnxRrJiZfzbPzYqyPIVmxA== Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id E797E25931; Thu, 5 May 2022 22:34:55 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Thu, 5 May 2022 15:34:54 -0700 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Content-Language: en-US To: Hans Petter Selasky , arch@FreeBSD.org Cc: gallatin@FreeBSD.org References: <04f80ff1-2374-8f49-ac13-1c55570cb6c0@selasky.org> From: John Baldwin Subject: Re: Time sharing for interrupt threads In-Reply-To: <04f80ff1-2374-8f49-ac13-1c55570cb6c0@selasky.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1651790096; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ifFQmnQ7iIR1pRicAZsQKES80us/Y2BvSxJI0WIJnTo=; b=n4ok+S4NOVX620cQlSCX08kUu3f+MuApjQCjYQ6xePs0UBX6IgWvGO5xM4wb4f7CkeNkNu xn0+S80dayLbqS0eaDrCByvOp+YWCksPNY4pJFqaC0OZNbMi2oDVjGIrdj4bLVoFKeBQ6b bglrx6KAl2IY912PD47qBA0g3XUXPNvYazV3Ko579cgsoz2jFRriQYjEFkFC680hQ9tmUU izE3TGlygLLUVa/48JRogkNxvszdSx8j7WAuEPBDQgwhV9YIieznOttTlyblVjxZ50Svor xL5mXrkf9aad1BImWg2BNTJ1DoXO7txFnbLc0e539gHQMVims7rI13N4FZaCDw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1651790096; a=rsa-sha256; cv=none; b=nG0tHSbdRa3VLXvBcHewvTiQRd9NK+RxEzeE4qCjzuLpRz+ojHOlZ7N6IUXzGVpLHWfj12 mDUAZpQODzuha+2p5WjEa0R1NJE5nUcnG2d2r/6JQOjkP1Oh1c1M1XFe4m5G4ltBG6rsjz I7SUMwkmp/W9nSKvbhAq2id2eKo/JoH1Q/KF/9nXz35PoeSClVJEsIfPl71y/PEjFCTnmN YXVb4JA88EFCeEJye8gHmRVQL9FeTIanTM+8A1tbyKwsRVYDPckKNA2P9P9yS/0ydon88P w2w/Djb121mmQeXC7tU4BSpTQCEEZvfG/3KX5DZo9/go4IFmg2jKsrQglRMDWw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 5/5/22 12:11 AM, Hans Petter Selasky wrote: > On 5/4/22 23:48, John Baldwin wrote: >> My recent changes to the softclock threads (raising their priority) were to >> address a livelock issue in which a constant stream of packets could starve >> timeout events. > > Sorry for short-cutting the thread, but why can't we have multiple > worker threads with different prio's for timers? In USB we have that, > once for Giant locked and non-Giant locked callbacks. I mean, all timer > interrupts are executed serially and any congested mutex will make all > succeeding timer callbacks halt on that CPU core! We do have per-CPU threads at least. However, this particular problem is orthogonal I think to the notion of if we want to enable time-sharing for ithreads in general. Having multiple workers for callouts raises its own interesting problems such as how you decide how to schedule callouts among multiple threads. I suspect that the number of callouts using Giant are fairly inconsequential at this point so Giant vs non-Giant probably isn't compelling. You could perhaps add some kind of scheduler-activations type thing where you either spawn or wakeup another thread when a callout handler blocks on a lock. That would be a fair bit of work though and not really related to this proposal. -- John Baldwin