From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31345 invoked from network); 5 Feb 2022 18:22:43 -0000 Received: from 4ess.inri.net (216.126.196.42) by inbox.vuxu.org with ESMTPUTF8; 5 Feb 2022 18:22:43 -0000 Received: from mail-il1-f176.google.com ([209.85.166.176]) by 4ess; Sat Feb 5 13:14:25 -0500 2022 Received: by mail-il1-f176.google.com with SMTP id z18so7666752ilp.3 for <9front@9front.org>; Sat, 05 Feb 2022 10:14:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=offblast-org.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=uKXesmMlIWUmFKku4gb81+tXP5UauppDsinWAPVgiTI=; b=buvag09kPHh0alUVpkmjzr6JlgzUEbhnrrYlJYAoKQt0+HXFUBy/KHYZ/2CJrCMJmv 4l0fv+OztCXnwiBRRn7yaskFbODb/41kmtaFPccdvvBcuh+h/o2pBPCJrOg+of+mGdql njQo6jZ6FCd8k5IbpY9rwMWAf1Pqg4QMPDiRfhDrFGn+sbqqnZBGuy/o2893YAQ1WJ1D Z193gIIRc7grgiDwmwjk9irQaybxHo+qE/NbzsDQlMMITWfJQfl3xuZLGdWwJ5XcyRMa kF/R27MQxdaYaJXAlIKHhDzoINlp1GJu3K/H2FssBW7I/E55q96l4O/jv4pN55r9x6he C3qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=uKXesmMlIWUmFKku4gb81+tXP5UauppDsinWAPVgiTI=; b=6OFpzslgmGJljHl1SR/gxCwNlgZJovQoxS2byNVVvKpe9IAFq2j2/YXyWM7b3wMsm0 ApfeA5I3cAQCl6PaXqlNAmtiZ4eQ16dJkro9TFfjjmtzMq3n/joJNMoJuxmU/S28FbiG 5lBNBPlo24xx2lKFT4PuKLKfkUEI4mwWxf7mHBj+Lv1DpCplmdjfiZhIXNHUxZw8mI6y sy5i1CipnssChvGVNY3lSNispfBXEc0mdfAIpLRENzKjl7X8GHamEXvPi7x2RWPQfsFn Y8eKRJG/v+ne1jvbauLZqjSxQdtN++NhaCwI2gNgCSaonQNLJV1SFIgmEolLgQ95se3W Ye2w== X-Gm-Message-State: AOAM531yFXINM+Kcfo0rVoJubBBhx2bYcz1dN0GspKfhh5BNwr//583s iwZKVRHHKqWsvJMwvIaNoSSb26EOrd/kqXYq5/1vBFSXdTTAXw== X-Google-Smtp-Source: ABdhPJxnJwms12ySlrSbxAdQoVno4XrY1yPDZ71CRHNfbnM8zfMG4ZE2wR0BhhG78z11cMExjGxheaKUdu+eCWJlUgs= X-Received: by 2002:a05:6e02:1566:: with SMTP id k6mr2313810ilu.207.1644084858662; Sat, 05 Feb 2022 10:14:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nick Owens Date: Sat, 5 Feb 2022 10:14:07 -0800 Message-ID: To: 9front@9front.org Content-Type: text/plain; charset="UTF-8" List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: ActivityPub software descriptor cache Subject: Re: [9front] qemu clock/timer issue Reply-To: 9front@9front.org Precedence: bulk kvm emulates a local APIC timer which the 9front kernel uses. the timer period is clamped to a minimum period, and my understanding is that the purpose is to protect the host from CPU consumption by guests, but i don't have a citation for that. 9front requests a timer period shorter than what the default minimum is and kvm warns about it. it maybe needs more investigation as to whether we really need such short timers. in the meantime, you can lower the timer period minimum with echo "options kvm min_timer_period_us=10" >> /etc/modprobe.d/kvm.conf which is 10000ns. it won't kill all of the warnings since sometimes the timer period is slightly shorter, but it will help with the dmesg spam. On Sat, Feb 5, 2022 at 7:30 AM Michael Forney wrote: > > I was recently running 9front in a VM on linux (qemu, with > -enable-kvm), and noticed several weird timing/clock issues. The date > command gives wildly varying results +- 1 minute: > > cpu% date > Fri Feb 4 17:39:23 PST 2022 > cpu% date > Fri Feb 4 17:39:12 PST 2022 > cpu% date > Fri Feb 4 17:40:19 PST 2022 > cpu% date > Fri Feb 4 17:39:18 PST 2022 > > `sleep 1` exits pretty much instantly, stats moves through the entire > width in a second or two, and clicking in scrollbars starts repeating > immediately. > > I notice the following messages in my dmesg: > kvm: vcpu 3: requested 38141 ns lapic timer period limited to 200000 ns > kvm: vcpu 1: requested 9449 ns lapic timer period limited to 200000 ns > kvm: vcpu 2: requested 51204 ns lapic timer period limited to 200000 ns > kvm: vcpu 0: requested 74421 ns lapic timer period limited to 200000 ns > > I don't remember this problem last time I ran 9front in qemu (around a > year ago), so I looked through commit history and found one commit > that seemed like it might be related: > http://git.9front.org/plan9front/plan9front/a05bab362f66ddd6fa65f2e7cda9eaaa0217ec08/commit.html > > To check, I tried setting *nohpet=1 in my plan9.ini, which *seems* to > have solved the problem, though I still see those same messages in > dmesg on the linux host (but now the requested lapic timer period is > always around 100000 ns or greater). > > Anyone know what's going on here?