Solved Using the system while building packages feels laggy.

[nxjoseph]

Hi. I use ZFS on Root, have a cpu with igpu (4 core 8 threads), 16GB RAM and 32GB SWAP on a M2 NVME disk. My problem is, While compiling packages in background, even though I didn't gave all my cpu threads to poudriere, my system feels laggy. I don't know what's causing the issue. I didn't limit RAM usage by poudriere, currently im building electron27 with all it's dependencies with PARALLEL_JOBS=4 (i guess that mean 4 threads will be used by poudriere).

% uname -aKU
FreeBSD desktop.home.lan 14.1-STABLE FreeBSD 14.1-STABLE stable/14-n267701-e73147fc7ca6 GENERIC amd64 1401500 1401500

 

[cracauer@]

No, it will use 4 units of CPU on different cores, aka no hyperthreading used. It is not using two hyperthreaded pairs.

 

[nxjoseph]

No, it will use 4 units of CPU on different cores, aka no hyperthreading used. It is not using two hyperthreaded pairs.

So I can increase PARALLEL_JOBS up to 4 max, because it doesn't use threads but physical cores. Does poudriere uses hw.ncpu to determine PARALLEL_JOBS by default? if so, why does it act like it uses hyperthreading because hw.ncpu returns 8 for me. Can I enable hyperthreading?

 

[cracauer@]

There is no such difference between a "real core" and a "hyperthreaded core". The core with its 2 threads is symmetric. The first user gets a full core worth. When the second user comes along for that air both get about 60% worth of a standalone core worth of CPU time.

 

[SirDice]

with PARALLEL_JOBS=4 (i guess that mean 4 threads will be used by poudriere).

No, it means poudriere will have 4 jobs running, each job can have something to build. Each individual build can use one or more threads.

 

[Charlie_]

If you want to reduce the impact of the build, use idprio(1).
sudo idprio 31 poudriere ...

 

[nxjoseph]

If you want to reduce the impact of the build, use idprio(1).
sudo idprio 31 poudriere ...

Only running idprio doesn't seem to work but when i use it with nice, it seems to reduce impact of the build. Also, I reduced number of jobs in make.conf.

# /usr/bin/nice -n 18 idprio 31 poudriere ...

Thanks all.

 

[nxjoseph]

Only running idprio doesn't seem to work but when i use it with nice, it seems to reduce impact of the build. Also, I reduced number of jobs in make.conf.

# /usr/bin/nice -n 18 idprio 31 poudriere ...

Thanks all.

To be fair, nice(1) and idprio(1) didn't make an effect as much as limiting the CPU cores for the build jobs, using cpuset(1), Kudos to who involved in creating it.

% grep -i cip /etc/csh.cshrc
alias cipopt    "cpuset -l 0-2 idprio 31 poudriere options -j 143amd64 -p default"
alias cipbulk   "cpuset -l 0-2 idprio 31 poudriere bulk -j 143amd64 -p default"
alias cipcln    "cpuset -l 0-2 idprio 31 poudriere pkgclean -j 143amd64 -p default"
alias ciptest   "cpuset -l 0-2 idprio 31 poudriere testport -j 143amd64 -p default"
alias cipopti386        "cpuset -l 0-2 idprio 31 poudriere options -j 143i386 -p default"
alias cipbulki386       "cpuset -l 0-2 idprio 31 poudriere bulk -j 143i386 -p default"
alias cipclni386        "cpuset -l 0-2 idprio 31 poudriere pkgclean -j 143i386 -p default"
alias ciptesti386       "cpuset -l 0-2 idprio 31 poudriere testport -j 143i386 -p default"

 

[Espionage724]

Is CPU frequency changing? Maybe something like a few cores turboing and hitting a limit from the compiler, them getting lowered, and (depending on CPU) it potentially affecting voltage or something else across the whole CPU?

There's also the fun of investigating USB controllers, interrupts across cores, scheduling, C-states, and HT/SMT enabled/disabled

 

[Barney]

You seem convinced it’s cpu, what evidence do you have that’s the problem? And what CPU is it? There’s a big difference between an E-2414 and a J1900. What’s your cpu usage? The higher the usage the greater the lock contention; performance will drop logarithmically as you approach 100%

That being said, these things are usually IO related; not cpu. Your disks will max out I/O way before a modern cpu.