| 1 |
On 3/1/2019 10:01, Mart Raudsepp wrote: |
| 2 |
> Ühel kenal päeval, N, 28.02.2019 kell 04:13, kirjutas Joshua Kinard: |
| 3 |
>> On 2/25/2019 05:18, Alexander Tsoy wrote: |
| 4 |
>>> В Пн, 25/02/2019 в 13:07 +0300, Alexander Tsoy пишет: |
| 5 |
>>>> В Чт, 21/02/2019 в 04:36 -0500, Joshua Kinard пишет: |
| 6 |
>>>>> Does anyone have an idea why util-linux's build time would go |
| 7 |
>>>>> up |
| 8 |
>>>>> significantly from 2.32.x to 2.33.x? It may be a MIPS thing, |
| 9 |
>>>>> as my |
| 10 |
>>>>> x86_64 |
| 11 |
>>>>> box shows no discernible change in build times between the same |
| 12 |
>>>>> versions. |
| 13 |
>>>>> Can any other archs check w/ genlop to see if they see a large |
| 14 |
>>>>> jump |
| 15 |
>>>>> in build |
| 16 |
>>>>> time? |
| 17 |
>>>>> |
| 18 |
>>>>> 'genlop -t util-linux' output on my SGI system (some entries |
| 19 |
>>>>> removed |
| 20 |
>>>>> for |
| 21 |
>>>>> brevity): |
| 22 |
>>>>> |
| 23 |
>>>>> Thu Feb 1 11:26:33 2018 >>> sys-apps/util-linux-2.31.1 |
| 24 |
>>>>> merge time: 27 minutes and 48 seconds. |
| 25 |
>>>>> |
| 26 |
>>>>> Sat Mar 31 08:07:20 2018 >>> sys-apps/util-linux-2.32 |
| 27 |
>>>>> merge time: 28 minutes and 44 seconds. |
| 28 |
>>>>> |
| 29 |
>>>>> Mon Aug 27 06:21:30 2018 >>> sys-apps/util-linux-2.32.1 |
| 30 |
>>>>> merge time: 32 minutes and 58 seconds. |
| 31 |
>>>>> |
| 32 |
>>>>> Tue Nov 13 10:03:58 2018 >>> sys-apps/util-linux-2.33 |
| 33 |
>>>>> merge time: 1 hour, 19 minutes and 49 seconds. |
| 34 |
>>>>> |
| 35 |
>>>>> Fri Jan 11 09:20:21 2019 >>> sys-apps/util-linux-2.33.1 |
| 36 |
>>>>> merge time: 1 hour, 23 minutes and 37 seconds. |
| 37 |
>>>>> |
| 38 |
>>>>> Thu Feb 21 04:14:33 2019 >>> sys-apps/util-linux-2.33.1 |
| 39 |
>>>>> merge time: 1 hour, 25 minutes and 15 seconds. |
| 40 |
>>>>> |
| 41 |
>>>> |
| 42 |
>>>> 2.33 was changed to use python-r1 eclass instead of python- |
| 43 |
>>>> single-r1 |
| 44 |
>>>> eclass. And the increase of build time seems caused by an out-of- |
| 45 |
>>>> source |
| 46 |
>>>> build for each python implementation. Some libraries are built |
| 47 |
>>>> several |
| 48 |
>>>> times (for native abi + for each python implementation). |
| 49 |
>>> |
| 50 |
>>> And there is additional configure run for each python |
| 51 |
>>> implementation. |
| 52 |
>> |
| 53 |
>> Hmm, this might explain things, somewhat. I think there's possibly |
| 54 |
>> some |
| 55 |
>> truth to the getcwd bit discussed earlier, but that may be limited to |
| 56 |
>> glibc |
| 57 |
>> only. |
| 58 |
> |
| 59 |
> Right, util-linux doesn't conduct that test. coreutils and tar do, |
| 60 |
> maybe some more. |
| 61 |
> That doesn't mean running with sandbox doesn't have a slowdown effect - |
| 62 |
> it most certainly does, just hopefully not so drastic as that |
| 63 |
> particular case - it involves glibc own generic getcwd being slow with |
| 64 |
> long paths, and sandbox calling it three times for its access checks |
| 65 |
> even for mkdir call, just to error with ENAMETOOLONG, in addition to |
| 66 |
> many getcwd calls the configure check itself does. So it's slow even |
| 67 |
> without sandbox, but with sandbox that slowness is doubled or more. |
| 68 |
> That has made me wonder if maybe by having some more ENAMETOOLONGs |
| 69 |
> earlier, the test would finish earlier, instead of slowly spinning |
| 70 |
> through paths that are in length between PATH_MAX and PATH_MAX*2, when |
| 71 |
> it's slow.. |
| 72 |
> But not sure why these m4 macros seems to be calling getcwd after each |
| 73 |
> mkdir+chdirm etc just to get a boolean configure check result. Didn't |
| 74 |
> look into the specific case, I only debugged the test case that just |
| 75 |
> loops mkdir+chdir. |
| 76 |
> Someone should maybe convert these project to meson and do that check |
| 77 |
> smarter :D |
| 78 |
> |
| 79 |
>> util-linux-2.33.1 on my uclibc-ng chroot took about ~25mins. Have to |
| 80 |
>> re-time the glibc build to see if it's something w/ the libc |
| 81 |
>> implementation. |
| 82 |
>> |
| 83 |
>> Temp workaround I guess is to cut down on the PYTHON_TARGETS before |
| 84 |
>> my next |
| 85 |
>> catalyst attempt. 2.7 + 3.7 should be enough... |
| 86 |
> |
| 87 |
> Personally I seem to get by with just USE=-python on util-linux (it's |
| 88 |
> actually not globally enabled on my systems, it seems). Otherwise, |
| 89 |
> sure, if the slowness is in configure. |
| 90 |
> |
| 91 |
> |
| 92 |
> Mart |
| 93 |
|
| 94 |
Yeah, I forgot I had a global 'python' USE set on the Octane. It's not been |
| 95 |
fun trying to disentangle the mess after removing it. But... |
| 96 |
|
| 97 |
Before: |
| 98 |
Thu Feb 21 04:14:33 2019 >>> sys-apps/util-linux-2.33.1 |
| 99 |
merge time: 1 hour, 25 minutes and 15 seconds. |
| 100 |
|
| 101 |
After: |
| 102 |
Sun Mar 3 03:22:26 2019 >>> sys-apps/util-linux-2.33.1 |
| 103 |
merge time: 18 minutes and 35 seconds. |
| 104 |
|
| 105 |
|
| 106 |
The above is also with sandbox disabled for now until the getcwd issue is |
| 107 |
fixed. If I'd known that sandbox slowed stuff down that much, I'd have |
| 108 |
stopped using it a long time ago. This machine is top of its class, but |
| 109 |
it's taking longer to build stuff as new versions come out due to new |
| 110 |
features being added, compiler taking longer, etc. I miss the days when |
| 111 |
this thing could build gcc in 3-4 hours. More like 14hrs now. |
| 112 |
|
| 113 |
-- |
| 114 |
Joshua Kinard |
| 115 |
Gentoo/MIPS |
| 116 |
kumba@g.o |
| 117 |
rsa6144/5C63F4E3F5C6C943 2015-04-27 |
| 118 |
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 |
| 119 |
|
| 120 |
"The past tempts us, the present confuses us, the future frightens us. And |
| 121 |
our lives slip away, moment by moment, lost in that vast, terrible in-between." |
| 122 |
|
| 123 |
--Emperor Turhan, Centauri Republic |
Archives