Gentoo Archives: gentoo-portage-dev

From: Sid Spry <sid@××××.us>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] Speeding up Tree Verification
Date: Wed, 01 Jul 2020 22:06:07
Message-Id: e1cd8450-fb23-4c28-941e-1e045168fd82@www.fastmail.com
In Reply to: Re: [gentoo-portage-dev] Speeding up Tree Verification by Fabian Groffen
1 On Wed, Jul 1, 2020, at 1:40 AM, Fabian Groffen wrote:
2 > On 30-06-2020 13:13:29 -0500, Sid Spry wrote:
3 > > On Tue, Jun 30, 2020, at 1:20 AM, Fabian Groffen wrote:
4 > > > Hi,
5 > > >
6 > > > On 29-06-2020 21:13:43 -0500, Sid Spry wrote:
7 > > > > Hello,
8 > > > >
9 > > > > I have some runnable pseudocode outlining a faster tree verification algorithm.
10 > > > > Before I create patches I'd like to see if there is any guidance on making the
11 > > > > changes as unobtrusive as possible. If the radical change in algorithm is
12 > > > > acceptable I can work on adding the changes.
13 > > > >
14 > > > > Instead of composing any kind of structured data out of the portage tree my
15 > > > > algorithm just lists all files and then optionally batches them out to threads.
16 > > > > There is a noticeable speedup by eliding the tree traversal operations which
17 > > > > can be seen when running the algorithm with a single thread and comparing it to
18 > > > > the current algorithm in gemato (which should still be discussed here?).
19 > > >
20 > > > I remember something that gemato used to use multiple threads, but
21 > > > because it totally saturated disk-IO, it was brought back to a single
22 > > > thread. People were complaining about unusable systems.
23 > > >
24 > >
25 > > I think this is an argument for cgroups limits support on the portage process or
26 > > account as opposed to an argument against picking a better algorithm. That is
27 > > something I have been working towards, but I am only one man.
28 >
29 > But this requires a) cgroups support, and b) the privileges to use it.
30 > Shouldn't be a problem in the normal case, but just saying.
31 >
32
33 cgroups kernel support is a fairly common dependency. It can obviously be optional,
34 I am thinking related to MAKEOPTS or EMERGE_DEFAULT_OPTS (see: rustc/cargo not
35 respecting or being passed -j/-l as another use for cgroups) and supported best-effort,
36 but is there any reason to expect it to not be enabled?
37
38 If the user isn't either root or portage I think it reasonable to leave resource management
39 to the machine's administrator.