# renicing di portage causa compilazioni lente [risolto]

## Guglie

ciao,

ho una macchina che non aggiorno da tre mesi. oggi ho notato che emerge ci mette tantissimo a compilare i pacchetti (fino a 20 volte il tempo che ci metteva tre mesi fa).

ho fatto un paio di verifiche: l'hard disk scrive e legge a velocità normali. il sistema non swappa, le partizioni non sono piene. in più compilando lo stesso pacchetto a mano i tempi di compilazione sono paragonabili a quelli antichi.

ora, non conoscendo bene emerge, non saprei bene come muovermi..  :Wink: 

vi posto qui la configurazione di portage:

```
# emerge --info

Portage 2.1.4.5 (default/linux/x86/2008.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.24-hardened-r3 i686)

=================================================================

System uname: 2.6.24-hardened-r3 i686 Intel(R) Pentium(R) 4 CPU 2.60GHz

Timestamp of tree: Tue, 23 Dec 2008 10:20:01 +0000

app-shells/bash:     3.2_p33

dev-java/java-config: 1.3.7, 2.1.6

dev-lang/python:     2.4.4-r14, 2.5.2-r6

dev-python/pycrypto: 2.0.1-r6

sys-apps/baselayout: 2.0.0

sys-apps/openrc:     0.2.5

sys-apps/sandbox:    1.2.18.1-r2

sys-devel/autoconf:  2.13, 2.61-r2

sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1

sys-devel/binutils:  2.18-r3

sys-devel/gcc-config: 1.4.0-r4

sys-devel/libtool:   1.5.26

virtual/os-headers:  2.6.23-r3

ACCEPT_KEYWORDS="x86"

CBUILD="i686-pc-linux-gnu"

CFLAGS="-O2 -march=i686 -fomit-frame-pointer -pipe"

CHOST="i686-pc-linux-gnu"

CONFIG_PROTECT="/etc"

CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d"

CXXFLAGS="-O2 -march=i686 -fomit-frame-pointer -pipe"

DISTDIR="/usr/portage/distfiles"

FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch"

GENTOO_MIRRORS="http://mirror.switch.ch/ftp/mirror/gentoo/  http://gentoo.mirror.solnet.ch/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo/"

LANG="en_GB.UTF-8"

LC_ALL="en_GB.UTF-8"

LDFLAGS="-Wl,-O1"

PKGDIR="/usr/portage/packages"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

PORTDIR_OVERLAY="/usr/local/portage/overlay /usr/local/portage/giliath_overlay"

SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"

USE="X aac acpi alsa apache2 bash-completion bzip2 cli cracklib crypt cups dbus dri dvb dvd flac fortran gdbm gif gpm gtk gtk2 hal iconv ipv6 isdnlog java jpeg midi mmx mmx2 mp3 mudflap ncurses nls nptl nptlonly ogg openmp oss pam pcre perl php png postgres pppd python readline reflection session spl sqlite sse sse2 ssl svg sysfs tcpd truetype unicode vorbis wma x86 xml xorg xvid zlib" ALSA_CARDS="snd-emu10k1" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="radeon"

Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
```

----------

## ckx3009

non conosco i profili hardened ma quel -march=i686 mi pare strano (tra l'altro non e' nemmeno riportata nel wiki sulle safe CFLAGS).

puoi postare "cat /proc/cpuinfo" ?

----------

## Guglie

 *ckx3009 wrote:*   

> non conosco i profili hardened ma quel -march=i686 mi pare strano (tra l'altro non e' nemmeno riportata nel wiki sulle safe CFLAGS).

 

ciao,

mi spaventi: uso queste CFALGS ormai da anni!  :Wink: 

citando "http://en.gentoo-wiki.com/wiki/CFLAGS":

"Here's an incomplete list of valid x86 architectures you may use with the -march flag:

i386,i486, i586, i686, pentium, pentium-mmx, pentiumpro, pentium2, pentium3, pentium-m, pentium4, prescott, k6, k6-2, k6-3, k8, athlon, athlon-tbird, athlon-4, athlon-xp, athlon-mp, athlon64, opteron, winchip-c6, winchip2, c3"

ai tempi misi i686 perchè oltre a questo pentium-4 avevo in giro anche un athlon a un pentium-m.

comunque il sistema di hardened ha solamente il kernel: niente patchs di sicurezza e niente profilo hardened.

 *Quote:*   

> puoi postare "cat /proc/cpuinfo" ?

 

certo:

```
 # cat /proc/cpuinfo 

processor   : 0

vendor_id   : GenuineIntel

cpu family   : 15

model      : 2

model name   : Intel(R) Pentium(R) 4 CPU 2.60GHz

stepping   : 9

cpu MHz      : 2600.000

cache size   : 512 KB

physical id   : 0

siblings   : 2

core id      : 0

cpu cores   : 1

fdiv_bug   : no

hlt_bug      : no

f00f_bug   : no

coma_bug   : no

fpu      : yes

fpu_exception   : yes

cpuid level   : 2

wp      : yes

flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pebs bts sync_rdtsc cid xtpr

bogomips   : 5190.98

clflush size   : 64

processor   : 1

vendor_id   : GenuineIntel

cpu family   : 15

model      : 2

model name   : Intel(R) Pentium(R) 4 CPU 2.60GHz

stepping   : 9

cpu MHz      : 2600.000

cache size   : 512 KB

physical id   : 0

siblings   : 2

core id      : 0

cpu cores   : 1

fdiv_bug   : no

hlt_bug      : no

f00f_bug   : no

coma_bug   : no

fpu      : yes

fpu_exception   : yes

cpuid level   : 2

wp      : yes

flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pebs bts sync_rdtsc cid xtpr

bogomips   : 5187.37

clflush size   : 64
```

----------

## ckx3009

citando http://en.gentoo-wiki.com/wiki/Safe_Cflags/Intel

```

Pentium 4

vendor_id  : GenuineIntel

cpu family  : 15

model  : 0 or 1 or 2

model name  : Intel(R) Pentium(R) 4 CPU XXXXMHz

CHOST="i686-pc-linux-gnu"

CFLAGS="-march=pentium4 -O2 -pipe -fomit-frame-pointer"

CXXFLAGS="${CFLAGS}"

```

quindi -march=pentium4

personalmente ti consiglio, se vuoi usare una versione piu' recente (~arch) di gcc delle serie 4.2 o 4.3, di utilizzare -march=native che e' l'autoriconoscimento del processore.

----------

## Ic3M4n

@ckx3009: l'utilizzo di pentium-4 o i686 è una scelta che uno fa. se utilizzasse pentium-4 non potrebbe spostare i pacchetti precompilati dagli altri computer. prima di sconsigliare qualcosa semplicemente perchè hai letto qualcosa da qualche parte pensa anche a tutte quelle distro che compilano ancora per i386 e magari l'utente mette il tutto su un quad core. secondo te il computer si accende? si accende e funziona.

----------

## ckx3009

Ic3M4n,

sicuramente, ma non e' che rispondo perche' "ho letto qualcosa da qualche parte".

lui si lamenta di tempi di compilazione lunghi, io provo a dargli una soluzione, l'unica che mi viene in mente, cosa che non sta facendo nessun altro.

quindi, oltre a "rimproverare" me, dai anche una mano a lui.

francamente preferisco che mi si diano soluzioni a tentoni al posto che lasciare senza alcuna risposta le mie domande, cosa che mi succede spessissimo.

a provare a compilare un pacchetto con 

```
CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe"  emerge pacchetto
```

ci mette poco. e vede se la lentezza e' data eventualmente dalla flag.

se non e' quello, semplicemente scrive "no, guarda anche cosi' non cambia nulla"

----------

## Guglie

suvvia, non siate così litigiosi: vi ringrazio entrambi per l'aiuto che avete certato di darmi  :Wink: 

compilando a mano con le flags di make.conf ci mette poco, quindi il problema non è nelle flags, ma in emerge o in qualche sua dipendenza.

andando a tentoni ho commentato la riga relativa a niceness in make.conf e i tempi sono ritornati normali.

per ora mi tengo il sistema così perchè ho parecchia roba da compilare, ma in futuro vorrei tornare a dare una priorità bassa a portage: sapete se è cambiato il sistema di renicing di portage? se ben mi ricordo lo mettevo a 15 su tutte le macchine senza che le compilazioni ne risentissero.

----------

## IlGab

 *Guglie wrote:*   

> 
> 
> andando a tentoni ho commentato la riga relativa a niceness in make.conf e i tempi sono ritornati normali.
> 
> 

 

Dettaglio non trascurabile visto che nelle info da te riportate non compariva  :Smile: 

Scusa la domanda scema, ma perchè non lo lasci girare una notte ad aggiornare il sistema invece che perderti dietro ai nice ?

----------

## Ic3M4n

@ckx3009: non ti stavo rimproverando, solo volevo mettere chiarezza sul fatto che la differenza tra pentium4 e i686 non porta differenze visibili nell'esecuzione del programma, tranne il fatto che se compili per pentium4 e poi metti il pacchetto tu un processore differente non va. quindi avendo differenti computer uno potrebbe preferire compilare su uno e poi esportare i pacchetti precompilati sull'altro, in questo modo puoi gestirli in un tempo minore. 

per quanto riguarda la compilazione... le cose più stupide che mi vengono in mente sono: portage ci mette di più perchè deve risolvere le eventuali dipendenze e quindi si deve leggere l'ebuild, applicare eventuali patch al sorgente originale e quindi possono aumentare notevolmente i tempi di compilazione. Una cosa interessante potrebbe essere, utilizzando genlop vedere i tempi di compilazione di pacchetti un mese fa, un anno fa ed adesso. in modo da non lasciare adito a dubbi sul fatto che effettivamente adesso ci mette di più a compilare.

----------

## ckx3009

 *Guglie wrote:*   

> suvvia, non siate così litigiosi [...]

 

non si tratta di esser litigiosi... e' solo che chi predica e non aiuta, potrebbe far a meno di predicare (secondo me).

in effetti non avrei mai pensato alla priorita' di emerge.

edit:  *Ic3M4n wrote:*   

> @ckx3009: non ti stavo rimproverando, solo volevo mettere chiarezza sul fatto che la differenza tra pentium4 e i686 non porta differenze visibili nell'esecuzione del programma

 

ma infatti io non parlavo di esecuzione del programma, ma solo dei tempi di compilazione.Last edited by ckx3009 on Wed Dec 24, 2008 12:23 pm; edited 1 time in total

----------

## !equilibrium

 *Guglie wrote:*   

> ma in futuro vorrei tornare a dare una priorità bassa a portage: sapete se è cambiato il sistema di renicing di portage? se ben mi ricordo lo mettevo a 15 su tutte le macchine senza che le compilazioni ne risentissero.

 

non è assolutamente cambiato il renicing di portage, al limite è cambiato il modo in cui il kernel gestisce il nice sui singoli processi, in modo particolare se hai attivato la voce:

```

General setup  --->

  [x] Control Group support

  [x] Group CPU scheduler

```

p.s.: per piacere auto-moderatevi e attenetevi alle linee guide, cioè se non sapete la soluzione al problema proposto da un utente, non commentate a caso, grazie.

----------

## !equilibrium

 *Ic3M4n wrote:*   

> Una cosa interessante potrebbe essere, utilizzando genlop vedere i tempi di compilazione di pacchetti un mese fa, un anno fa ed adesso. in modo da non lasciare adito a dubbi sul fatto che effettivamente adesso ci mette di più a compilare.

 

cio avrebbe senso soltanto sulla stessa versione del pacchetto, perchè se ci sono macroscopiche differenze a livello di codice sorgente tra due versioni (la versione 1.0 è di soli 2MB mentre la versione 1.1 è di 100MB) non ha alcun senso affermare: "emerge compila lento" perchè è giusto che sia così, i sorgenti sono più corposi.

----------

## Guglie

 *IlGab wrote:*   

> 
> 
> Dettaglio non trascurabile visto che nelle info da te riportate non compariva 

 

già: emerge --info non lo include.. scusate  :Wink: 

 *Quote:*   

> Scusa la domanda scema, ma perchè non lo lasci girare una notte ad aggiornare il sistema invece che perderti dietro ai nice ?

 

certo, ora lo lascio compilare in pace, ma avere un nice alto fa comodo quando compilo e in più lavoro su quella macchina.

@!equilibrium: grazie, dopo installo il kernel nuovo e ci guardo dietro

ad ogni modo prima mi riferivo a un pacchetto piccolo e l'incremento di tempo era abbastanza netto..

```
# qlop -tgH dev-libs/libpcre

libpcre: Thu Sep 28 04:13:17 2006: 1 minute, 2 seconds

libpcre: Tue Jan  2 17:28:06 2007: 1 minute, 7 seconds

libpcre: Fri Nov 30 17:17:31 2007: 2 minutes, 11 seconds

libpcre: Wed Mar 19 23:05:27 2008: 2 minutes, 18 seconds

libpcre: Mon Mar 24 23:42:09 2008: 2 minutes, 35 seconds

libpcre: Thu Jul 31 00:57:40 2008: 2 minutes, 16 seconds

libpcre: Tue Dec 23 13:35:49 2008: 45 minutes, 36 seconds

libpcre: Wed Dec 24 12:08:49 2008: 4 minutes, 37 seconds

libpcre: Wed Dec 24 12:14:05 2008: 2 minutes, 10 seconds

libpcre: Wed Dec 24 12:16:42 2008: 2 minutes, 18 seconds

libpcre: 10 times
```

----------

## Ic3M4n

 *!equilibrium wrote:*   

>  *Ic3M4n wrote:*   Una cosa interessante potrebbe essere, utilizzando genlop vedere i tempi di compilazione di pacchetti un mese fa, un anno fa ed adesso. in modo da non lasciare adito a dubbi sul fatto che effettivamente adesso ci mette di più a compilare. 
> 
> cio avrebbe senso soltanto sulla stessa versione del pacchetto, perchè se ci sono macroscopiche differenze a livello di codice sorgente tra due versioni (la versione 1.0 è di soli 2MB mentre la versione 1.1 è di 100MB) non ha alcun senso affermare: "emerge compila lento" perchè è giusto che sia così, i sorgenti sono più corposi.

 

verissimo ma quante volte capita questo? soprattutto su alcuni pacchetti di gnome il cambio di versione non è altro che un bump del pacchetto precedente per rimanere allineati con il numero di versione, quindi a parte casi particolari potrebbe essere uno strumento più accurato del "ad occhio mi sembra che sia più lento perchè le linee nel terminale scorrono più lentamente."

@Guglie: in effetti così sembrerebbe, tieni comunque conto che se fai partire compilazioni parallele o nel frattempo utilizzi in maniera intensa il computer è normale che i tempi di compilazione si alzino, altra idea potrebbe essere vedere lo scheduler del kernel ed il timing, se li hai cambiati potresti generare più context switch e quindi aumentare il tempo di compilazione, in ogni caso non credo che i tempi si allunghino tanto.

----------

## Guglie

mh, ieri l'altro non ero troppo lucido..  penso, ma non garantisco niente, che a causa del nice alto emerge desse la priorità al caro mpd, che nel frattempo non capiva più niente, perchè si era staccato il cavo dell'hard disk con i files multimedia..

scusate la vaccata..   :Rolling Eyes: 

----------

## djinnZ

le mie cflags (ed uso hardened quindi conosco meglio i problemi tipici perchè ci bestemmio quotidianamente) sono "-O2 -march=athlon-xp -fforce-addr -fomit-frame-pointer -pipe", usare l'ottimizzazione generica -march=i686 con le corrispondenti -msse & C ti consente di creare codice portabile ma implica il rischio che qualche pacchetto non funzioni bene perchè le ottimizzazioni non vengono filtrate (-march=athlon-xp implica -msse & C).

Se il filtraggio di -msse per esempio è fatto a livello di ebuild bene ma se è fatto a livello di autotools o direttamente nel make forzando solo -march=i686 (mi pare che mplayer o squid facciano così) rischi che non vengano filtrate delle flag pericolose.

Considera che il gcc ottimizzato per cpu è più veloce ed interagisce meglio con il kernel (se è stato compilato per il supporto alla specifica cpu) quindi anche se vuoi creare dei binari portabili potresti pensare di compilare il gcc e binutils ottimizzati per il tuo processore. Lo dico perchè vedo che hai le use corrispondenti attive.

-fforce-addr è stata aggiunta di default perchè aiuta la smash proptection ed ha un bizzarro impatto sulla compilazione in alcuni casi la rallenta, in altri, rari, la rende più veloce, ma su alcune cpu bacate (come il mio sempron) ha lo strano effetto di ridurre i crash per internal error, non ho ancora capito perchè ma è così (solo su gcc 3.x hardened ovviamente).

Vedi che dal kernel 2.6.23 il sanitize freed memory ed alcune altre opzioni funzionano a pieno ma rallentano molto la macchina, forse è il caso che pensi ad un kernel alternativo o disabiliti alcune protezioni per compilare. Per migliorare la gestione dell'allocazione devi impostare compat_brk=y se usi la randomizzazione di pax (o c'era un parametro che non ricordo da linea di comando o da sysctl da impostare a 2 o 0 piuttosto che lasciarlo al default 1).

Frettolosamente, a parte quel che ha detto equilibrium, CONFIG_PREEMPT=Y  ed abilitare il preempt rcu (ovviamente fglrx te lo scordi con queste impostazioni) ma non il tracing non mi viene a mente altro.

----------

