Re: [gentoo-portage-dev] Speeding up Tree Verification

["Sid Spry" <sid@aeam.us>]

On Wed, Jul 1, 2020, at 1:40 AM, Fabian Groffen wrote:
> On 30-06-2020 13:13:29 -0500, Sid Spry wrote:
> > On Tue, Jun 30, 2020, at 1:20 AM, Fabian Groffen wrote:
> > > Hi,
> > > 
> > > On 29-06-2020 21:13:43 -0500, Sid Spry wrote:
> > > > Hello,
> > > > 
> > > > I have some runnable pseudocode outlining a faster tree verification algorithm.
> > > > Before I create patches I'd like to see if there is any guidance on making the
> > > > changes as unobtrusive as possible. If the radical change in algorithm is
> > > > acceptable I can work on adding the changes.
> > > > 
> > > > Instead of composing any kind of structured data out of the portage tree my
> > > > algorithm just lists all files and then optionally batches them out to threads.
> > > > There is a noticeable speedup by eliding the tree traversal operations which
> > > > can be seen when running the algorithm with a single thread and comparing it to
> > > > the current algorithm in gemato (which should still be discussed here?).
> > > 
> > > I remember something that gemato used to use multiple threads, but
> > > because it totally saturated disk-IO, it was brought back to a single
> > > thread.  People were complaining about unusable systems.
> > > 
> > 
> > I think this is an argument for cgroups limits support on the portage process or
> > account as opposed to an argument against picking a better algorithm. That is
> > something I have been working towards, but I am only one man.
> 
> But this requires a) cgroups support, and b) the privileges to use it.
> Shouldn't be a problem in the normal case, but just saying.
> 

cgroups kernel support is a fairly common dependency. It can obviously be optional,
I am thinking related to MAKEOPTS or EMERGE_DEFAULT_OPTS (see: rustc/cargo not
respecting or being passed -j/-l as another use for cgroups) and supported best-effort,
but is there any reason to expect it to not be enabled?

If the user isn't either root or portage I think it reasonable to leave resource management
to the machine's administrator.