kerneldove: cpuset would pin it to whatever cores you limit it to, rctl would let it run on all but potentially throttle it every second or so

kevans, is the throttling smooth and just slows down jail's usage or is it an abrupt halt kinda thing?

is cpuset more efficient or any other advantage to using it vs setting rctl pcpu to 100%?

kerneldove: my recollection of how the cputime rctl is implemented is that it's not really smooth, but worth trying for yourself anad observing

ok i'll just cpuset 1 core for each jail, then use rctl to limit memory. ty kevans

if aesni kernel module is included by default now, why's it still (as of 14.3) added to /boot/loader.conf pls?

specifically aesni_load="YES"

and i see also cryptodev_load="YES" is still in 14.3 /boot/loader.conf, but i thought if aesni is used (and it's included by default in GENERIC supposedly) then cryptodev shouldn't be loaded also

kerneldove: according to usr.sbin/bsdinstall/scripts/zfsboot, it's added automatically if you install on GELI to ensure crypto is accelerated. this seems reasonable because aesni might not be compiled into the kernel

but it's added automatically to GENERIC right? aesni i mean

cryptodev is what lets you use hardware crypto (like AES-NI) from userland, so you need both if you want to do that and your hardware has AES-NI

yes, aesni is in GENERIC, so if you're running GENERIC you can remove that from loader.conf

i searched GENERIC for "aes" didn't find. is it implied with device crypto?

kerneldove: cgit.freebsd.org/src/tree/sys/amd64/conf/GENERIC?h=releng/14.3#n308

i was looking at github.com/freebsd/freebsd-src/blob/master/sys/amd64/conf/GENERIC

shouldn't they match?

kerneldove: you're looking at the wrong branch, go here: github.com/freebsd/freebsd-src/blob/main/sys/amd64/conf/GENERIC

wtf

the master branch should probably be deleted from github, it doesn't exist in src anymore, i'll mention that to imp

tyvm

surprised github didn't give option to redirect master -> main

so if we have aesni loaded, which is automatic with GENERIC, we also want cryptodev loaded so the aesni can be used from userspace?

probably yes, although i'm not sure how userland consumers handle this... AES-NI isn't privileged so they could just call it directly if they have support

hm ok. i read (can't find link now) that dev crypto which is included in GENERIC supercedes cryptodev which is older and slower so cryptodev isn't actually needed anymore. know anything about that?

i don't know the answer to that

ivy found a link opnsense/tools #26

specifically opnsense/tools #26#issuecomment-193367846

that seems like a different issue to do with openssl using cryptodev instead of its own AES-NI implementation... and it's 10 years old so it might have been fixed

> I don't think that OpenVPN requires cryptodev, it uses OpenSSL's evp engine which is capable of using the AES-NI instructions without using the aesni module. If OpenSSL finds cryptodev and aesni is loaded, then it will use cryptodev and slow things down.

but redmine.pfsense.org/issues/5976 where it talks about perf being lower it doesn't mention openssl so maybe it's more general?

but yea it is pretty old issue

i guess since 14.3 adds cryptodev_load="YES" i'll use it too. i figure devs would have removed it by now if it was actually better to not have it

do you know how we can see if 15 still adds it? i'll look for " usr.sbin/bsdinstall/scripts/zfsboot" in a 15 branch

i found it with "git grep aesni_load", so try that

github.com/freebsd/freebsd-src/blob…usr.sbin/bsdinstall/scripts/zfsboot is for 15 right? if so, it doesn't add cryptodev anymore!?

yes, main is 15 (at least for now, it will become 16 shortly when stable/15 is branched)

oh but github.com/freebsd/freebsd-src/blob…usr.sbin/bsdinstall/scripts/zfsboot doesn't have cryptodev in it either

hey check out freebsd/freebsd-src ffbaa45

zfsboot adds aesni, not cryptodev, i don't know where cryptodev_load comes from off hand

github.com/freebsd/freebsd-src/blob…/usr.sbin/bsdinstall/scripts/config looks removed

looks like it's on its way out as of 15!

we got to the bottom of it together

github.com/freebsd/freebsd-src/blob…in/bsdinstall/scripts/zfsboot#L1403 looks like aesni_load="YES" IS still added to loader.conf when zfs encryption (geli) is enabled as of 15

so i'll use it too

ty

hi everyone, recently i discovered we can run docker in freebsd with docker-machine, for some reason my laptop likes this virtualbox more than bhyve. i'm saying this only because when running bhyve, cpu is going up to 80 degrees but with virtualbox, cpu barely raises temp. I cannot find any source distinguishing these two performance wise, far as I know docker should have the same con as resource consuming

as bhyve. anyone has any tips? Thanks.

wow

i thought bhyve was prety mature?

file a bug.

How do I run /usr/local/wine-proton/bin/pkg32.sh install wine-proton mesa-dri in a Jail? I am getting an error: pkg -o ABI_FILE=/usr/lib32/libc.so.7 -o INSTALL_AS_USER=true -o RUN_SCRIPTS=false --rootdir /home/jailuser/.i386-wine-pkg install wine-proton mesa-dri pkg: Unable to determine the ABI, none of the ABI_FILEs can be read.

(there is no /usr/lib32/libc.so.7 in the jail.. presumably for security porpoises :) )

pertho: you probably need the lib32 set to install 32-bit package, that includes 32-bit libc

I installed the jail with Bastille.. guess I had to modify it . thanks!

what's the best way to make sure linprocs (/proc) is mounted in the jail?

set allow.mount.linprocfs (read the note in jail(8)) then you should be able to mount it in the jail's /etc/fstab

ah right.. so the allow.mount.linprocfs needs setting first then add it to the /etc/fstab?

hm, although looking at the rc script, jails may not mount from fstab

apparently /etc/rc.d/linux is supposed to do this, but it looks like it's not set up to run in a jail

as a workaround you could mount it using a jail-specific fstab on the host (mount.fstab)

bastille has a fstab under jails/jailname/

but I'm not sure what to put in it to mount /proc

would have thought I would need to nullfs mount /proc from the host?

do you want Linux /proc or FreeBSD /proc? usually linprocfs is mounted on /compat/linux/proc

hmm that's a good question.. I was testing this WINE app with FreeBSD's /proc but I wonder if Linux's /proc would be more compatible with it since this WINE app uses some linuxisms to detect things..

because I don't fully trust the app, I want to send it to jail :)

Hi

well, either way procfs(4) and linprocfs(4) both document the required fstab entry, so if bastille has an fstab for the jail, you can put it there. normally a jail fstab needs the jail root prepended to the mountpoint, but i don't know if bastille works like that, i've never used it

got another strange staff here :P

I fixed it but wanted to mention that since the new upgrade, I am getting wrong architecture error Msgs when using pkg add; to install some old stuff..

For example: wrong architecture: FreeBSD:11:amd64 instead of FreeBSD:13:amd64

I even can't force install it, this wasn't happening in 13.2

ivy: 'bastille mount <jailname> /compat/linux/proc /proc' seems to have done the trick

To make it persistent you should add it to the jail's fstab: `bastille edit <jail> fstab`

if I wanted to trace whether a WINE app I'm running is failing due to W^X or ASLR constraints, what's the best tool to determine that? ktrace/kdump doesn't seem to give enough useful output. Do I try dtrace? (I've never used dtrace before)

also the WINE debugging is a bloody nightmare.. produces gigs of logs which are near impossible to parse

Try truss(1)

doesn't seem to help either.. I get a bunch of freebsd32_mmap() calls which end in ERR#12 'Cannot allocate memory'

is it normal for truss to keep running and make the cpu race after the app has quit?

the app I'm truss'ing keeps running in the background somehow

I don't think truss(1) is the right tool for this

If it's some old Windows program you may change the Windows version to an older one in winecfg. Or just run it in a vm

Is there a public progress bar for the package builders? :)

yeah

is the in progress main build

Oh wow. Just found out why that link didn't work last time I tested -- *.freebsd.org is on my unbound blocklist. Wtf.

rude

Very.

don't leave that page open

its pull a 7MB json file in a loop

Oops. I SSH'ed in and pkill -9 firefox now. Sorry :(

I think we need something like LTS for Freebsd

Still fixing many broken stuff, while I will need to upgrade after 7 months for now..

*from

LTS ? each major release is LTS

mzar: even minor ones break

Look at Solaris it's LTS lasts for nearly +25 years

we have a hard enough time supporting releases that are only 4-5 years old

realistically we do not have the resources

I am a desktop user, FreeBSD devs need to take care of us

are you funding freebsd development?

the oldest supported Solaris release was released in 2015, which is 10 years ago, comparable to Ubuntu and RHEL, and if you've used Solaris, you know that patches frequently break things - the update releases are just as risky as upgrading FreeBSD x.y to x.y+1

this is very demanding without a plot for where the resourcing comes from

heh, no

the reality is that we're a volunteer project without a real corporate backer to make things like this feasible

kevans: I can make something better, if you need resources I can afford a big part of it

fwiw, if you have money, you're free to provide your own support for older freebsd releases for as long as you want

there's no actual reason freebsd.org needs to do that, necessarily

(also, i tend to think ports support is a much more serious issue, but no one wants to fund that because most large corporate users aren't using ports, because it's not reliable, so kind of a vicious circle)

Then you need resources for ports?

ports is a complicated problem, i don't think you can just throw money at it

Not money

src is pretty straightforward in comparison

but Servers

mosaid: sure, we need, CPU cyccles for building, hands for testing and maintaing ports tree, feel free to help

servers would improve build times, but what it really needs is developers, and maybe management

How much resources do you have right now?

sorry for being dick-ish here, this is a thing that comes up not infrequently and often folks just don't understand how our project is developed

mosaid: TBH, desktop users are key users, don't hesitate to install FreeBSD on you PC

I never used any kind of OS rather than Freebsd for nearly 6 years

and I liked it

OK, that's excellent

But when upgrade time comes..

I found that when upgrade time comes I often mess things up because I didn't RTFM and still do certain things the same way I've done it for 20+ years :D

I am running old school upgrades, (make ...) that's best, supported since the beginning

mzar: my installation is super complicated, new stuff + old stuff (really really old stuff)

easy to break

I'm trying to setup Skylake GT2 [HD Graphics 520]. Do I only need to install drm-kmod and add i915kms to the kld_list?

every time I update something will surly break

same here, my systems were installed in early 2000s and are continuously upgraded (those from 1990 are already wiped)

Old user then.. nice :)

lessless2: I think yes

see this very useful

Back again to resources, I will try to afford some of my servers in near future

if you needed that

physical resourcing isn't the only consideration in a request like that, though

like, yes, we would need more builders, more space to mirror out packages, etc., but we also need the people-resources to actually backport on that kind of timeline

even just four years down the line, the tree will look significantly different than it does today

things get more and more non-trivial to backport, that time has to come from somewhere

kevans and all involved: good job, thanks for your hard work !

Some strange question could I run Linuxulator with centos and ubuntu installed in same time?

Like will it cause some problem when sharing the same directories

mosaid: there is a sysctl value: compat.linux.emul_path: Linux runtime environment path. I think that means only one linux emulation environment can be run at the same time.

it defaults to /compat/linux

on all my servers i see like 8 getty command processes running in ttyin state. is that ram going to waste?

* asdasd

ivy: how did you write your last msg?

nxjoseph: it's called in action, in most IRC clients "/me does something" is the command for it

s/in action/an action

ivy: thanks!

im new in irc

nxjoseph, Most IRC clients consume lines that start with a / such as /me or /join or /part. But what if you want to start a line with something like /usr/local/bin ? In that case use the /say action. /say /usr/local/bin will not consume the /usr part as a command and will say it.

rwp: / /

kerneldove, Multiple processes will share code pages in memory. You need to have at least one getty running for being able to log into the console. Having a small number of additional of those processes running will consume a miniscule amount of copied-on-written data memory since there is little data there. Having 8 getty processes versus 1 or 2 is insignificant of resources but hugely useful when needed.

It's also a good reason that having swap configured is useful. If the kernel needs memory and there are pages wasted holding something that isn't being used then those pages can be pushed to swap storage and the ram freed up for use for other things. It's all dynamic, automatic, and useful.

ah ok

tyvm

kerneldove: yes, that's the beauty of it i'm 100% sure. but what's happening is intersting, running docker microservices for a web doesnt cause as much cpu as bhyve... if i want to fire up like 3 byhve hosts on my laptop, it would burn... not sure why.

tsoome: XD they will say go back to dig yourself why.

_opr maybe file a bug with a reproducible case?

kerneldove: problem is is this qualified as a bug, no issues when using bhyve and it's solid, just performance wise, eating a lot of CPU and that's it. It's always the case, fireup byhyve host, my laptop CPU is about 70-80 degrees, yet not much impact from those docker containers (3 at least). What I have in mind is these containers are all running in one docker-machine host on virtualbox, but again, it's

virtualbox we're talking about. Just my guess. I'll see what I can do. thx guys.

_opr, sure, performance outliers are helpful for devs to know about. just do all you can to make it concise and include reproducibility steps

devs are really good about addressing bug reports when we make it easy for them

Usually I just say "it doesn't work" and pat myself on the back for another fine bug report. /s

XD

kerneldove: Thanks for the tips.

yw