| View previous topic :: View next topic |
| Author |
Message |
Tinitus
Veteran
Joined: 20 Sep 2004
Posts: 1754
|
 Posted: Thu Feb 25, 2010 11:58 am Post subject: Intel Core 2 Quad 64 bit Kernel |
 |
|
Hallo,
möchte gerne einen 64bit Kernel für ein Core2Quad optimieren.
Deshalb suche ich ein paar Tipps bzw. habe noch Verständnisprobleme:
1. Welche Prozessorfamilie
Core 2
Generic x86-64
Intel PIV
Preemption Model
Preemptible Kernel (Low-Latency Desktop) oder doch nicht?
Timer frequency
250 Hz
Default I/O scheduler
CFQ
Kernel compression mode
Initial RAM filesystem and RAM disk (initramfs/initrd) support
gzip
bzip2
LZMA
LZO
ScaleMP vSMP?
sonst noch irgendwelche wichtigen Sachen?
G. R. |
|
| Back to top |
|
 |
Randy Andy
Veteran
Joined: 19 Jun 2007
Posts: 1152
Location: /dev/koelsch
|
| Posted: Thu Feb 25, 2010 12:57 pm Post subject: |
|
|
Hi Tinitus,
wieso hab ich auf einmal so'n pfeifen auf den Ohren 
Ich arbeite mit genau so einem System zu Hause, kann aber gerade nicht nachsehen, daher aus'm Kopf in anlehnung an deine Vorgaben:
1.) Prozzi = Core2, Generic willst du nicht da du optimieren möchtest!
Preemtion nimmst du Desktop (falls du mit 'ner DE arbeitest, wovon ich ausgehe und nicht als Server), aber nicht low latency, es sei denn du weisst warum du das dringend brauchst - warum würde jetzt zuweit führen...
Timer frequency
1000 Hz
Default I/O scheduler
CFQ
Kernel compression mode
Initial RAM filesystem and RAM disk (initramfs/initrd) support
gzip (LZMA macht wohler eher für ARM-arch Sinn, weils da schneller dekompremiert, aber beim Quad kannste ruhig beim bewährten Zip bleiben)
Scale SMP bei Mehrkernprozzi unbedingt! (daher als USE Flag dann später threads sertzen)
Mehr Vorgaben gab's nicht, ev. später meine Config wenn zu Hause an der Konsole
Gruß, Andy.
_________________
If you want to see a Distro done right, compile it yourself! |
|
| Back to top |
|
|
tazinblack
Veteran
Joined: 23 Jan 2005
Posts: 1146
Location: Baden / Germany
|
| Posted: Thu Feb 25, 2010 4:51 pm Post subject: |
|
|
| Randy Andy wrote: | Preemtion nimmst du Desktop (falls du mit 'ner DE arbeitest, wovon ich ausgehe und nicht als Server), aber nicht low latency, es sei denn du weisst warum du das dringend brauchst - warum würde jetzt zuweit führen...
Timer frequency
1000 Hz
Default I/O scheduler
CFQ
Scale SMP bei Mehrkernprozzi unbedingt! (daher als USE Flag dann später threads sertzen)
|
Also warum nicht die "low latency" Variante würde mich schon interessieren. Auch, warum Du den Timer Takt so hoch drehst.
CFQ oder was anderes ist sicher auch ne Glaubensfrage, wobei ich gefühlt bisher wenig Unterschied festgestellt hab.
_________________
Gruß / Regards
tazinblack
_______________________________________________________
what's the point in being grown up if you can't be childish sometimes |
|
| Back to top |
|
|
Randy Andy
Veteran
Joined: 19 Jun 2007
Posts: 1152
Location: /dev/koelsch
|
| Posted: Thu Feb 25, 2010 5:43 pm Post subject: |
|
|
Ich fang mal mit dem einfachsten an, der Glaubensfrage 
Die hat sich nämlich erledigt da man andere ebenfalls gute Strategien bereits in den CFQ implementiert hat, und ihn auch künftig weiter optimieren möchte.
Deshalb hat man sich vom Anticipatory I/O Scheduler (AS), der laut Commit-Kommentar nur eine Untermenge der Funktionen des CFQ-Schedulers bietet, seit kernel 2.6.33 getrennt. Gut du könntest noch den deadline I/O scheduler nehmen...
Die low latency Einstellung emfhielt sich afaik als real time kernel, wenn es besonders auf geringe Latenzzeiten ankommt, z.B. für Musikproduktionen wo es keinen Versatz zwischen verschiedenen Quellen geben darf. Oder für Echtzeitsteuerung / Analyse von Zeitkritischen Bus-Systemen oder sonstigen Anwendungen.
Das hat aber seine Preis, da die Echtzeit (isses garnicht, aber halt geringe Latenz) absolute Priorität erhält - Nachteil: der i/o Durchsatz sinkt dafurch.
Ergo, fährt der normale Desktop u. Multimedia-Anwänder (ja, auch Videoschnitt) mit | Code: | | Voluntary Kernel Preemption (Desktop) |
besser!
1000Hz war halt damit sich das System in seiner Reaktion noch schneller anfühlt, aber nicht die Nachteile von low latency hat, sehe aber gerade dass ich nun doch besser auf 300Hz gehen werde, wegen dem Videoschnitt mit PAL Rate/Auflösung.
Entscheidet selbst ob Enbildung oder Glaubensfrage, hier die Argumente:
| Code: | 250 HZ (HZ_250)
CONFIG_HZ_250:
250 Hz is a good compromise choice allowing server performance
while also showing good interactive responsiveness even
on SMP and NUMA systems. If you are going to be using NTSC video
or multimedia, selected 300Hz instead. |
| Code: | 300 HZ (HZ_300)
CONFIG_HZ_300:
300 Hz is a good compromise choice allowing server performance
while also showing good interactive responsiveness even
on SMP and NUMA systems and exactly dividing by both PAL and
NTSC frame rates for video and multimedia work. |
| Code: | 1000 HZ (HZ_1000)
CONFIG_HZ_1000:
1000 Hz is the preferred choice for desktop systems and other
systems requiring fast interactive responses to events. |
| Code: | Voluntary Kernel Preemption (Desktop) (PREEMPT_VOLUNTARY)
CONFIG_PREEMPT_VOLUNTARY:
This option reduces the latency of the kernel by adding more
"explicit preemption points" to the kernel code. These new
preemption points have been selected to reduce the maximum
latency of rescheduling, providing faster application reactions,
at the cost of slightly lower throughput.
This allows reaction to interactive events by allowing a
low priority process to voluntarily preempt itself even if it
is in kernel mode executing a system call. This allows
applications to run more 'smoothly' even when the system is
under load.
Select this if you are building a kernel for a desktop system. |
| Code: | Preemptible Kernel (Low-Latency Desktop) (PREEMPT)
CONFIG_PREEMPT:
This option reduces the latency of the kernel by making
all kernel code (that is not executing in a critical section)
preemptible. This allows reaction to interactive events by
permitting a low priority process to be preempted involuntarily
even if it is in kernel mode executing a system call and would
otherwise not be about to reach a natural preemption point.
This allows applications to run more 'smoothly' even when the
system is under load, at the cost of slightly lower throughput
and a slight runtime overhead to kernel code.
Select this if you are building a kernel for a desktop or
embedded system with latency requirements in the milliseconds
range. |
zur genaueren Info für Tinitus meine gesamte kernel config von 2.6.32-gentoo-r7, und wenn ich jetzt gleich xconfig schließe, dann wird 2.6.33 gebaut
http://paste.pocoo.org/show/182594/
Gruß, Andy.
_________________
If you want to see a Distro done right, compile it yourself! |
|
| Back to top |
|
|
tazinblack
Veteran
Joined: 23 Jan 2005
Posts: 1146
Location: Baden / Germany
|
| Posted: Sat Feb 27, 2010 9:10 am Post subject: |
|
|
Aha, danke mal für die Infos.
Ich werde wohl auch mal n bisschen dran rumbasteln.
_________________
Gruß / Regards
tazinblack
_______________________________________________________
what's the point in being grown up if you can't be childish sometimes |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Deutsches Forum (German)
