Optimale kernel compile params

Pagina: 1
Acties:

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
Ik weet intussen hoe ik mijn kernel kan compileren (ben noob) Maar ik krijg het niet voor elkaar om de optimale kernel compile settings te krijgen. Ik compileer als voor de 686 en maak gebruik van gcc 2.96.

Je kunt in je /etc/profile de volgende regel plaarsen:
export CFLAGS=-O9 -funroll-loops -ffast-math -malign-double -mcpu=pentiumpro -march=pentiumpro -fomit-frame-pointer -fno-exceptions

maar ik dit gaat niet op voor de kernel omdat deze (zijn Makefile) die instellingen weer override. Ik dus aan de slag met mijn Makefile maar ik krijg het maar niet voor elkaar dat ie die parameters slikt.

dit heb ik aangepast:
HOSTCFLAGS= -Wall -Wstrict-prototypes -O9 -funroll-loops -ffast-math -malign-double -mcpu=pentiumpro -march=pentiumpro -fomit-frame-pointer -fno-exceptions


CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -o9 -funroll-loops -ffast-math -malign-double -mcpu=pentiumpro -march=pentiumpro -fomit-frame-pointer -fno-exceptions

en dit is de foutmelding bij make bzImage:

sched.c:697: Can`t find a register in class 'GENERAL_REGS' while reloading 'ams'

Wat is zo vreemd vind is dat deze foutmelding is gekomen door het veranderen van die parameters. (Ik heb hier trouwens een verse source voor gebruikt).

Ik heb de topics al doorgeploegd maar nergens een passend antwoord voor mijn probleem gevonden. Ik hoop dat jullie mij verder kunnen helpen, want dan kan ik straks ook die nieuwe kernel erin plakken :7

  • imdos
  • Registratie: Maart 2000
  • Laatst online: 05-08 12:09

imdos

I use FreeNAS and Ubuntu

Ik kan je wel vertellen dat die settings misschien in sommige gevallen optimaal zullen zijn .. maar bij mij is het al voorgekomen dat meerdere dingen erdoor niet willen compilen. Dus ben ik er maar weer van afgestapt en doe alleen -O3 -march=athlon (p.s. daar heb je gcc 3.0.x voor nodig afaik)

pvoutput. Waarom makkelijk doen, als het ook moeilijk kan! Every solution has a new problem


  • igmar
  • Registratie: April 2000
  • Laatst online: 29-06 18:56

igmar

ISO20022

dit heb ik aangepast:
HOSTCFLAGS= -Wall -Wstrict-prototypes -O9 -funroll-loops -ffast-math -malign-double -mcpu=pentiumpro -march=pentiumpro -fomit-frame-pointer -fno-exceptions


CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -o9 -funroll-loops -ffast-math -malign-double -mcpu=pentiumpro -march=pentiumpro -fomit-frame-pointer -fno-exceptions

en dit is de foutmelding bij make bzImage:

sched.c:697: Can`t find a register in class 'GENERAL_REGS' while reloading 'ams'

Wat is zo vreemd vind is dat deze foutmelding is gekomen door het veranderen van die parameters. (Ik heb hier trouwens een verse source voor gebruikt).
Gewoon lekker van afblijven. De settings zijn als optimaal als je de juiste architectuur kiest. Tenzij je erg goed weet waat je mee bezig bent : Gewoon lekker zo laten.

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
maar bv dat loopunrollen kan toch geen kwaad? Het is gewoon het herschrijven van lussen. Ik zou het gek vinden als het daarom niet zou compilen. Maar missschien hebben jullie gelijk. Ik heb al genoeg library props. Ik ga zo gauw ik dit beetje onder de knie heb over op debian. Daar gaat het echt makkelijk. En mandrake (gebruik ik) geeft aan een aantal zaken zijn eigen draai, en dat staat me niet aan.

:'( geen zwaar geoptimaliseerde kernel.. maar eens kijken wat ik nog meer kan compileren. Denk dat ik xfree86 maar eens te grazen neem :)

  • deadinspace
  • Registratie: Juni 2001
  • Laatst online: 16-08 16:08

deadinspace

The what goes where now?

Merk op dat bepaalde hoge optimalisaties (-Ox voor x > 2 iirc, dus -O9 zeker) problemen kunnen geven met de code die gcc dan uitspuugt, als in: die kan dan fouten bevatten.
En als je kernel die fouten heeft krijg je lekker oopses en panics enzo ;)

De Makefiles van de kernel doen al optimizing waar nodig/verstandig meen ik, voor de rest kun je er (tenzij je erg avontuurlijk ingesteld bent) vanaf blijven.

Juiste architectuur kiezen in de config (dus bijv mbv make menuconfig) is uiteraard wel verstandig.

Verwijderd

Op vrijdag 15 maart 2002 23:50 schreef Alarmnummer het volgende:
:'( geen zwaar geoptimaliseerde kernel.. maar eens kijken wat ik nog meer kan compileren. Denk dat ik xfree86 maar eens te grazen neem :)
Zoals deadinspace net al zegt, da's niet zo handig nee :).

X kun je wel heerlijk optimizen, daar heb ik in het verleden al eens iets over geschreven (kan ik wel ff opzoeken). Algemeen geldt: "compileer, maar optimizeer met mate" ;).

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
Op zaterdag 16 maart 2002 09:21 schreef beelzebubu het volgende:

[..]

Zoals deadinspace net al zegt, da's niet zo handig nee :).

X kun je wel heerlijk optimizen, daar heb ik in het verleden al eens iets over geschreven (kan ik wel ff opzoeken). Algemeen geldt: "compileer, maar optimizeer met mate" ;).
Lijkt me leuk om te lezen. Ik geloof dat x standaard is gecompileerd voor de 386 (correct me if I`m wrong). Dus naar een 686 te compileren kan zeker geen kwaad. Maar is het bij jou veel sneller geworden?

ps: lijkt me leuk om dat stuk te lezen.

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

De kernel schijn je _niet_ te moeten optimaliseren...

Lijkt me ook erg onverstandig, aangezien dat de kern van je systeem is. Die _moet_ stabiel zijn.

Standaard maken de nieuwe kernels al een redelijk optimale kernel door bijvoorbeeld voor Athlon's te compileren etc. O9 specificeren is sowieso al vragen om problemen (compileer je apache maar es met -O9 en probeer de Zend optimiser te gebruiken... Mij lukte het iig niet)

Daarnaast moet je je natuurlijk ook afvragen of de 'extra instabiliteit' opweegt tegen de extra performance.
Zoveel scheelt het niet kwa performance in de meeste gevallen (niet of nauwelijks merkbaar dacht ik).

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
Ik vind het vreemd dat geoptimaliseerde code niet hetzelfde is al niet geoptimaliseerde code. In principe zou het toch exact dezelfde werking moeten hebben? (antwoord niet nodig, is namelijk ja :) )

offtopic:
Je leert onder linux veel meer dan onder windows. Je krijgt bv veel meer inzicht in het hele netwerk gebeuren.

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

Op zaterdag 16 maart 2002 10:24 schreef Alarmnummer het volgende:
Ik vind het vreemd dat geoptimaliseerde code niet hetzelfde is al niet geoptimaliseerde code. In principe zou het toch exact dezelfde werking moeten hebben? (antwoord niet nodig, is namelijk ja :) )
Toch niet...

Bij -O1, -O2 en -O3 is in de meeste gevallen (geldt al niet helemaal meer voor -O3) de werking hetzelfde.

Voor de hogere niveau's (vooral -O9 dus) wordt zelfs de 'werking' veranderd (weliswaar het eindresultaat niet, maar wel het traject volgens mij) het door mij gestelde voorbeeld is er een van. Na de compilatie van php/apache op -O9 kan de php-executable niet meer werken met de Zend-library (die vast op -O3 of -O2 gecompileerd is) samenwerken, resulterend in Coredumps als je dat wel probeert.

Als het goed is wordt dat ook allemaal uitgelegd in de documentatie van gcc, zou je es op moeten zoeken.

[edit]
Volgens mij staat het ook in allerlei documenten over het compileren van kernels dat je absoluut niet hoger dan -O2 moet optimaliseren. Mede omdat sommige delen van de kernel dan ineens niet meer goed werken.
De kernel is dan ook een van de weinige stukken linux die ik nooit geoptimaliseer zou compilen (behalve de parameters die de eigen config al samensteld)

Verwijderd

Op zaterdag 16 maart 2002 09:57 schreef Alarmnummer het volgende:

[..]

Lijkt me leuk om te lezen. Ik geloof dat x standaard is gecompileerd voor de 386 (correct me if I`m wrong). Dus naar een 686 te compileren kan zeker geen kwaad. Maar is het bij jou veel sneller geworden?

ps: lijkt me leuk om dat stuk te lezen.
Het is geen heel stuk, gewoon een post ergens op dit forum ;)

[topic=345352/1/25]

Als je op google zoekt zul je enkele dingen als -funroll-loops en -mdouble-align vinden die ook een (minimaal) verschil kunnen maken, maar met datgene wat daar staat zou je al een aardig eind moeten komen.

Het maakt bij mij i.i.g. een merkbaar verschil, ik hoor hier een aantal mensen die klagen dat X onwerkbaar sloom is (of linux in het algemeen) en daar heb ik sowieso al geen last van (ook al heb ik een P-II 400-tje), ik denk dat dit daarop wel van invloed is. Ik heb ook voor en na compilatie een groot verschil in werkbaarheid in X gemerkt, denk hierbij aan reactiesnelheid, algemene beeldopbouw, opstartsnelheid etc.

Ik gebruikte zelf overigens -O4, maar ik vraag me af of je veel hoger moet gaan... Ik vond -O4 wel genoeg, je kunt altijd -O6 proberen, maar be prepared dat het dan opeens niet meer werkt ;)

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
Ik heb linux er opnieuw opgezet (had het verneukt), en heb de kernel gecompileerd. Althans een poging gewaagd, want ik krijg nu de volgende foutmelding:
#error No fonts configured
en dan in bestand:/include/fonts.c

Ik neem aan dat ik een lib niet geinstalleerd heb, maar hoe vind ik uit welke? Heb trouwens de search al geprobeerd, maar niets gevonden.

Verwijderd

XFree86 bestaat uit 3 tar.gz's.
De 2e of 3e bevat de fonts.
Deze heb je alle drie nodig.

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
Ik heb xfree86,xfee86-75/100dpi-fonts,xfree86-libs en xfree86-devel er opgezet. Maar de fout die blijft.

Verwijderd

Op zaterdag 16 maart 2002 14:37 schreef Alarmnummer het volgende:
#error No fonts configured
Je hebt geen X configuratie

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
hmmm.. ik heb gewoon die config file van mijn vorige compile op mijn windows partitie neer gezet. En toen de nieuwe linux source neergezet. Toen make xconfig gedaan, en later mijn oude config file over de net gemaakte geplakt. En toen begonnen met het compileren van de kernel. Dat vond ie zeker niet leuk :)
Pagina: 1