From nobody Mon Nov 21 19:06:47 2022 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 4NGH1n2qZ9z4hGQB for ; Mon, 21 Nov 2022 19:06:53 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (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 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NGH1n0YhSz3lkD; Mon, 21 Nov 2022 19:06:53 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qv1-xf30.google.com with SMTP id d13so2921471qvj.8; Mon, 21 Nov 2022 11:06:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=3iCaF2xYga9UuFFzymJ2tueolh9FbZSFPVWoRGhAZp0=; b=fd3N61C0XOQjZlrLmmbs29VPoR15d9SAaEMjaZgJMoFqVaA08MYzJ7yaq3uwNBz7W6 XRVh3tBRXM1DzNonZlnOBJZXo050EH0NtxTAkg6l8/Ss6t1qGRchc9ex+pSp5IWxqveF UaathFnW8l4/kcczTMgHryVcCK6jnOJpE3+1yWNb6C+I0e3fVhL8XB2bfWi3Krghb67E qM0guJHcd5GEi1OYPitzlDBY1SKftrFHBULVPDuZoUSQje+PKqAdZzPu6Cag0FVwtA2i YwMw9/TTmwoM6G7CKlE6IZTMSYC9tyNlO1I/QOEsewVrht+Phf0bXxRglPpsELvDnw7h mcog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=3iCaF2xYga9UuFFzymJ2tueolh9FbZSFPVWoRGhAZp0=; b=Rl/wMKO2d1Bf/AjhN6vE7NgQhSKw3hAiwygayICJ26LHEF0DFRx0DGbgL707vxUonB xSy/9aqO/sFIKFMcH4cR3/igIG/f8PwGtDClH61/5x9zkEflfOGNpiaol0Wu1YMxUT/d qEh/pyCh2LeWxT5Xuamj/HHOnTM7jAJmM12YS0NvY5WbdDFuW8C+IBx8Pgy8hR4MOD82 iVb+rKqjZcPMpgvpZruSJwK+tSFV+RaeQ9zTaJcxmZvxk5Zvfq1dvEVii3i4fNzNtfPf kLiwKKi1xOIcMJ/L/ovpesxgKHNxs0lMwhvHVlxRONTPZ6E35qw5u+XsNS/+3giixzix eNhw== X-Gm-Message-State: ANoB5pkvbYANaPg7AM+8qCrGRd4+HB6LGpHdRgyA45uyGPTjt3aULPOr UqmwauADM9johvHJ9ipAvAVPPlcPujw= X-Google-Smtp-Source: AA0mqf7YbFOeiTu5sc4nWQU2YUYha/h5XFTDxhBKYXzBX3beDqeW2F48/o6mCV3SIYyhMyUyIZK4Pg== X-Received: by 2002:ad4:53c5:0:b0:4bb:7171:a3ee with SMTP id k5-20020ad453c5000000b004bb7171a3eemr6201918qvv.88.1669057611165; Mon, 21 Nov 2022 11:06:51 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id bp34-20020a05620a45a200b006fb0e638f12sm8900043qkb.4.2022.11.21.11.06.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Nov 2022 11:06:50 -0800 (PST) Date: Mon, 21 Nov 2022 14:06:47 -0500 From: Mark Johnston To: "Bjoern A. Zeeb" Cc: freebsd-hackers@freebsd.org Subject: Re: Can we "pause" in loader and ddb>? Message-ID: References: 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4NGH1n0YhSz3lkD X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Mon, Nov 21, 2022 at 06:42:44PM +0000, Bjoern A. Zeeb wrote: > Hi, > > having a VM sitting (a) in loader prompt or (b) in ddb> makes the fans > go loud on a test-laptop which makes one wonder if we can avoid that. > Note -- I assume also on real HW though that's less likely observered > here. > > For example I am sitting in a 4 vCPU bhyve current in ddb> and two > threads are at 100% on the base system. Do we need to heat up the > planet doing that or are there alternatives? I haven't looke dta the > code in ages and I assume we need to poll in these situations on the > console and for interactivity often enough? Can we "pause"? And why > would two [v]CPUs be at 100% and not just one as I would expect all but > one to be stopped? When DDB is active, one CPU is going to be spinning in cncheckc() waiting for input, and the others will be in cpustop_handler(). For the latter, there is an option to use MWAIT/MONITOR to pause the CPU instead of calling pause in a loop, but bhyve hides the MWAIT/MONITOR CPU capability from guests (I'm not sure exactly why), so they just execute "pause" in a loop, which won't help the apparent CPU usage. Note that when the kernel panics, cpustop_handler() will execute "hlt", which should result in a vmexit if you started bhyve with -H, and you'll see only one vCPU thread consuming 100% when sitting at the DDB prompt. But when you enter DDB without a panic, we need some mechanism to resume the stopped CPUs when exiting DDB.