Pre-Emptives-Multitasking: Timer?

[Coda]

Welches Bauteil erzeugt eigentlich die Frequenz mit der die Task-Switches durchgeführt werden?

[Trap]

Der Timer des APIC nehme ich mal an.

8.5.4 in ftp://download.intel.com/design/Pentium4/manuals/25366817.pdf

[Coda]

Hö? Im 64bit Modus gibts kein HW-Task-Switching mehr :|

[klutob]

IMHO der "Read Time-Stamp Counter" (RDTSC) in der CPU, zumindest nutzt diesen Linux für die scheduler switches.

[Coda]

Das Ding erzeugt keinen Interrupt, das kann nicht sein.

Ich finde wirklich nirgends Infos zu dem Thema, sehr seltsam...

[Demirug]

Früher hat man das über den 8253 Zähler Baustein gemacht. Ich könnte morgen mal im NT Inside nachschauen ob dazu was geschrieben wird.

[Trap]

Hö? Im 64bit Modus gibts kein HW-Task-Switching mehr :|
Wie kommst du darauf? Hat das irgendwas mit meiner Antwort zu tun?

[Coda]

Steht in der System Programming Guide von Intel (und auch in der von AMD in der ich danach nachgeschaut habe).

[avalanche]

Hö? Im 64bit Modus gibts kein HW-Task-Switching mehr :|O_o - wie switcht man denn dann? Alles per Hand retten wie "frueher"?

[Muh-sagt-die-Kuh]

Früher hat man das über den 8253 Zähler Baustein gemacht. Ich könnte morgen mal im NT Inside nachschauen ob dazu was geschrieben wird.Im Prinzip ist das immer noch so.

Aktuell wird der 8254 (http://www.stanford.edu/class/cs140/projects/pintos/specs/8254.pdf) verwendet, der bei meinem i875P (und wohl allen intel-Chipsätzen) logisch am LPC Interface der Southbridge hängt...eine separater Chip dürfte es aber schon lange nicht mehr sein.

[Demirug]

O_o - wie switcht man denn dann? Alles per Hand retten wie "frueher"?

Wieso früher? Ich frage mich eher ob diese Task Gate Geschichte jemals benutzt wurde.

[avalanche]

Wieso früher? Ich frage mich eher ob diese Task Gate Geschichte jemals benutzt wurde.Mh, ich weiss es nicht. Erschien mir mehr oder weniger sinnvoll, weil wenig Aufwand. Bzw. "wenig Aufwand" weiss ich auch nicht, hab's nie selber gemacht, aber es klingt doch ersteinmal nicht unpraktisch. Rettet man die ganzen zum Task gehoerenden Sachen wirklich "per Hand" (in ein Task-State-Segment?)?

[Demirug]

Wenn man es per Software macht kann man natürlich seine eigene Datenstruktur nehmen. Die Fibers werden bei Windows NT auf jeden Fall per Software gewechselt und die richtigen Threads AFAIK auch. So aufwendig ist das ja auch nicht.

[Coda]

Wieviel Zeit vergeht denn pro Task ungefähr und kann das OS das einstellen?

[Muh-sagt-die-Kuh]

Wieviel Zeit vergeht denn pro Task ungefähr und kann das OS das einstellen?Willst du wissen, wieviel Zeit ein Task-Switch braucht? Und ob das OS zwischen Task-Gate und Software-Switch wechseln kann?

[Coda]

Nein, wie lang eine App läuft pro Zeitscheibe.

[Trap]

Klar kann das OS das einstellen. Es kann einmal die Abstände der Timer-Interrupts einstellen und andererseits auswählen wieviele Timer-Interrupts eine Anwendung am Stück laufen darf.

[avalanche]

Wieviel Zeit vergeht denn pro Task ungefähr und kann das OS das einstellen?Nein, wie lang eine App läuft pro Zeitscheibe.Das kommt drauf an :) Die Zeitscheiben werden ja so oder so vom Scheduler bemessen, die Hardware kann ja bestenfalls Mitteilung machen, wieviel der Zeit denn schon rum ist. "OS" laesst darauf schliessen, dass es dich allgemein interessiert und nicht nur Windows-spezifisch sein soll. Die Zeitscheibenlaenge ist, Ueberraschung, prioritaetsabhaengig, also:
* Minimum timeslice is 5 msecs (or 1 jiffy, whichever is larger),
* default timeslice is 100 msecs, maximum timeslice is 800 msecs. * task_timeslice() scales user-nice values [ -20 ... 0 ... 19 ]
* to time slice values: [800ms ... 100ms ... 5ms]
*
* The higher a thread's priority, the bigger timeslices
* it gets during one round of execution. But even the lowest
* priority thread gets MIN_TIMESLICE worth of execution time.
Wobei man zu den beiden Kommentaren aus dem Linux-Quellcode noch sagen muss, dass die Werte, die hier angegeben werden, so berechnet werden:#define MIN_TIMESLICE max(5 * HZ / 1000, 1)
#define DEF_TIMESLICE (100 * HZ / 1000)...und man HZ (ich hoffe, dass es das ist) inzwischen ueber die Kernelkonfiguration aendern kann.# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250Man kann also zwischen 100, 250 und 1000 waehlen. So 100%ig hab ich die Berechnung der timeslices aber noch nicht durchdrungen, das ist nur erstmal das, was ich spontan in den Kernelquellen gefunden hab. Ist aber durchaus interessant :)

[Trap]

Scheduling von Windows ist auf http://www.microsoft.com/mspress/books/sampchap/4354c.asp erklärt.

[zeckensack]

Das kommt drauf an :) Die Zeitscheiben werden ja so oder so vom Scheduler bemessen, die Hardware kann ja bestenfalls Mitteilung machen, wieviel der Zeit denn schon rum ist. "OS" laesst darauf schliessen, dass es dich allgemein interessiert und nicht nur Windows-spezifisch sein soll. Die Zeitscheibenlaenge ist, Ueberraschung, prioritaetsabhaengig, also:

...Auf Windows haben Zeitscheiben konstante Länge, egal welche Priorität die Threads haben. Generell sollte ein Windows-Programm nie die Prioritäts-APIs benutzen.

[Muh-sagt-die-Kuh]

Nein, wie lang eine App läuft pro Zeitscheibe.Um es noch für Windows-Systeme zu ergänzen, Quelle ist das verlinkte Buch von Sysinternals Guru Mark Russinovich.

Die Intervalle von Timer-Interrups sind Hardware abhängig, betragen auf Uniprozessor x86 Systemen aber normalerweise 10 ms. Eine App läuft dann 20 ms (6 Quanten, bei jedem Timer-Interrupt Quanten -= 3) auf Windows 2000 Professional und 120 ms (36 Quanten) auf Windows 2000 Server @ Default Settings.

[Muh-sagt-die-Kuh]

Generell sollte ein Windows-Programm nie die Prioritäts-APIs benutzen.Von sich selbst macht das auch kein mir bekanntes Programm....ich kenne nur einige Encoder, die den Benutzer die Basis-Priorität des Prozesses in der Maske setzen lassen und dafür eben die API nutzen. Normale Benutzer können hier maximal eine "Higher" (= Basislevel 13) Priorität setzen, für "Realtime" (= Basislevel 24) braucht es normalerweise Administrator-Privilegien.