> -----Original Message----- > From: Wol <antli...@youngman.org.uk> > Sent: Wednesday, September 20, 2023 3:07 PM > To: gentoo-user@lists.gentoo.org > Subject: Re: [gentoo-user] Controlling emerges > > > What you have is not a portage problem. It is a orthodox parallelism > > problem, and I think you are thinking your constraint is unique in the > > work - it isn't. > > With parallelism, trying to fiddle single nodes to improve things > > overall never really works out. > > > A big problem you are missing is that portage does not have control of the > system. It can control its usage of the system, but if I want emerge to use > as much SPARE resource IN THE BACKGROUND as it can without impacting on > on-line responsiveness, that is HARD. > > I would like to be able to tell portage "these programs are resource hogs, > don't parallelise them". If portage has loads of little jobs, it can fire > them off one after the other as resource becomes available. If it fires a hog > (or worse, two) off at the same time, the system can rapidly collapse under > load. > > Even better, if portage knew roughly how much resource each job required, it > could (within constraints) start with the jobs that required least resource > and run loads of them, and by firing jobs off in order of increasing > demandingness, the number of jobs running in parallel would naturally tail > off. > > At the end of the day, if the computer takes an extra 20% time, I'm not > bothered. If I'm sat at the computer 20% time extra because the system isn't > responding because emerge has bogged it down, then I do care. And when I'm > building things like webkit-gtk, llvm, LO, FF and TB, they do hammer my > system. If they're running in parallel, my system would be near unusable. > > Cheers, > Wol
Maybe take a look at "cpulimit" out of the repos. I used to use it on one of my low-power systems to control how much load the various compilers were allowed to put on the system so that it could keep doing other tasks. I think there are some other, similar tools as well. LMP
