Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 10 Mar 2018 19:15:22 +0400
From:      Roman Bogorodskiy <novel@FreeBSD.org>
To:        "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net>
Cc:        freebsd-virtualization@freebsd.org
Subject:   Re: Call for testing bhyve cpu topology additions
Message-ID:  <20180310151520.GA19476@kloomba>
In-Reply-To: <201803071714.w27HE31L054613@pdx.rh.CN85.dnsmgr.net>
References:  <201803071714.w27HE31L054613@pdx.rh.CN85.dnsmgr.net>

next in thread | previous in thread | raw e-mail | index | archive | help

--X1bOJ3K7DJ5YkBrT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

  Rodney W. Grimes wrote:

> There is a new version of the CPU topology review up at
> 	http://reviews.freebsd.org/D9930
>=20
> I would like to ask that if people can test this and provide
> feedback that they do so.
>=20
> It has some undesired side effects on vm-bhyve and probably
> other down stream tools, I am in the process of contacting
> the vm-bhyve author to see what can be done to clean up
> this output (if you are here please respond to this thread):
>=20
> src-topo # vm list
> NAME            DATASTORE       LOADER      CPU    MEMORY    VNC         =
         AUTOSTART    STATE
> issd30g1        default         bhyveload   cpus=3D8,sockets=3D2,cores=3D=
4,threads=3D1 1024M     -                    No           Stopped
>=20
> Notice that due to the new CPU string being much more complicated than
> the normal int it makes the output format ugly.  I have another change
> to vm-bhyve that I would like to see too, and that is to move the NAME
> to the end of the line and remove the 16 character limit.   I have done
> that in my local copy already.  This string and its parsing are designed
> to be Qemu compatible.
>=20
> Here is a sample of my local vm-bhyve vm list output (no topology used):
> /tmp # vm list
> DATASTORE       LOADER      CPU    MEMORY    VNC                  AUTOSTA=
RT    STATE            NAME
> default         bhyveload   1      128M      -                    No     =
      Stopped          fb-bld-10-amd64
> default         bhyveload   1      128M      -                    No     =
      Stopped          fb-bld-11-amd64
> default         bhyveload   1      128M      -                    No     =
      Stopped          fb-bld-11.0-p1-amd64
> default         bhyveload   1      128M      -                    No     =
      Stopped          fb-bld-11.0-p1-i386
> default         bhyveload   4      512M      -                    No     =
      Stopped          fb-bld-11_1-amd64
> default         bhyveload   4      512M      -                    No     =
      Stopped          fb-bld-11_1-i386
> default         bhyveload   2      256M      -                    No     =
      Running (30227)  fb-bld-head-amd64
>=20
> Thoughts are to teach vm-bhyve to parse the string just as bhyve does
> and only output the vCPU count.  Other thoughts I have are to have
> it parse the string and output either vCPU if cores/threads is 1,
> or a simple S/C/T string.
>=20
> If you are a downstream maintainer of one of the other vm management pack=
ages
> I am open to input.  The implemntation I have done should allow any exist=
ing
> tool that treated -c as a string to use the new topology without changes.
> This includes the in base vmrun.sh.

My general input on adding new features to bhyve is that it would be
nice to have a way to detect if the given bhyve version supports this
specific feature.

In this specific case it looks like this could be checked by running

  bhyve -c gibberish

and checking if the error message contains 'invalid cpu topology'
string.

But generally it would be good to have some more convenient way of doing
that because running bhyve to probe each feature is pretty expensive.

By the way, looking at the DR, it seems that the usage output (bhyve -h)
wasn't updated, but maybe I'm missing that without context.

> Also people using the sysctls:
> 	hw.vmm.topology.cores_per_package: 1
> 	hw.vmm.topology.threads_per_core: 1
> can continue to do so at this time, but there is work in process to
> deprecate these, that work includes making stable/11 emit a warning
> message if they are used, and remove them in head/12.
>=20
> If I can get some significant test results back I plan to commit
> D9930 to ^head and merge it back to stable/11 3 days later.
>=20
> Thanks,
> --=20
> Rod Grimes                                                 rgrimes@freebs=
d.org

Roman Bogorodskiy

--X1bOJ3K7DJ5YkBrT
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJao/aIAAoJEMltX/4IwiJq5joH/A7qOM+9sZm3SgS9rZQRjAVS
bjh0H4UGA7wzYmADqfug0TZif+h0nn8Gz5rWhH858lZLeqzHA9TdJfht5D59I9xe
0r834O3slDD9tOtMoJyiQkqZxi8IsJbA3mw5q2Kk0wQ6vLguKgV3rRJlH0ZvexeK
LI0NVUxwjtlodbKwF7/EjzqFmGm/qylDx90D5sZGhw9wevziUwJUvTSJXMpWX/uE
1/HHhgJuBkPi6V/6IxQzsC2Td9k47uESwfPtpNK4rTvG4fXeWPHA0IlaLCRdK0J/
mx00BblXss1FlvTyPeKuTktXT8wwakwBItbaJ00U4+FrrSGrc1anqvkZUjiV7Do=
=mSPD
-----END PGP SIGNATURE-----

--X1bOJ3K7DJ5YkBrT--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180310151520.GA19476>