Arbeitet TAP_MemAlloc() nur blockweise ???

[Jag]

Hallo,

ich experimentiere gerade weitergehend mit TAP_MemAlloc() und musste leider feststellen, dass der verbrauchte Speicher immer blockweise belegt wird!

Egal ob ich 10 Byte oder 1000 Byte anfordere, verbraucht werden anscheinend immer 1280 Byte (+ x Byte für die Verwaltung)!
(1280 Byte = hex: 0x500 Byte)
Ab 1281 Byte wird dann das doppelte verbraucht (also 2*1280=2560+x Byte), usw. 3x, 4x ...!

Ist das allgemein bekannt, Topf spezifisch oder ein Bug :

Außerdem scheint TAP_MemAlloc() mit rund 4 ms pro Aufruf nicht gerade schnell zu sein

Das durchkreuzt leider einiges, so dass ich hier wohl wieder irgendwie "drumherumprogrammieren" muss

Kann das jemand bestätigen, kann man das verhindern ?

Hier eine Testfunktion dazu, dabei wird 5000-mal TAP_MemAlloc aufgerufen:

Code: Alles auswählen

void test_memalloc()
{
	int i;
	void *test_p;
	char strBuf[128];
	dword heapSize, freeHeapSize, availHeapSize;

	TAP_MemInfo(&heapSize, &freeHeapSize, &availHeapSize );
	TAP_SPrint(strBuf, " HeapSize: %d  free: %d  available: %d  GetTick: %d ", heapSize/1000, freeHeapSize/1000, availHeapSize/1000, TAP_GetTick() );
	TAP_Osd_PutString1622( rgn, 60, 250, -1, strBuf, COLOR_User14, COLOR_User1);

	for( i=0 ; i < 5000 ; i++ )
	{
		TAP_MemInfo(&heapSize, &freeHeapSize, &availHeapSize );

		if( availHeapSize > 100000 )
		{
			test_p = TAP_MemAlloc(10);  // oder ...(1000);
		}
	}

	TAP_MemInfo(&heapSize, &freeHeapSize, &availHeapSize );
	TAP_SPrint(strBuf, " HeapSize: %d  free: %d  available: %d  GetTick: %d ", heapSize/1000, freeHeapSize/1000, availHeapSize/1000, TAP_GetTick() );
	TAP_Osd_PutString1622( rgn, 60, 280, -1, strBuf, COLOR_User14, COLOR_User1);
}

(dass der Speicher hier nicht freigegeben wird spielt keine Rolle,
sollte ohne weitere TAP's gestartet werden und benötigt ca. 20 sec bei Ausführung)


Gruß
Jag

[eber]

Zumindest hatte ich bisher auch den Eindruck, das die Speicherverwaltung nicht besonders effizient ist. Auch habe ich das Gefühl, das es Performance-Probleme gibt wenn man relativ viele einzelne Bereiche anfordert (so ab 50 aufwärts).
Allerdings habe ich noch keine konkreten Experimente dazu unternommen. Ich versuche bisher so selten wie möglich TAP_MemAlloc aufzurufen.
Leider scheint die Firmware auch an dieser Stelle mit heißer Nadel gestrickt zu sein

Grüße

Eber

[ibbi]

Ist das allgemein bekannt, Topf spezifisch oder ein Bug :

So etwas scheint mir das normale Vorgehen für Speicherverwaltung zu sein. Der Kern des Betriebssystems fordert immer Blöcke an (z. B. 4 KByte), die der Prozessor optimal verwalten kann.

Will nun ein Programm 1 Byte Speicher, wird zunächst einmal ein neuer Block angefordert. Aus diesem Block werden so lange Anfragen befriedigt, bis er komplett aufgebraucht ist. Dann wird ein neuer Block angefordert.

So etwas muss sein, damit die Speicherverwaltung effizient durchgeführt werden kann und ist so lange kein Problem, wie genug Speicher zur Verfügung steht. Systeme mit wenig Speicher tun sich bei so etwas natürlich schwer.

[DeJe]

Jap, nach meinen kurzen Erkenntnissen (allerdings auch nicht konkret getestet) muß es so sein das malloc auf dem Topf nur fixed size Blöcke allociert.

Ich denke nicht das Du das verhindern kannst. Du kannst höchtens deine eigene Speicherverwaltung schreiben. Einen großen Block allocieren und dann diesen selbst als Heap benutzen. Speichereffizienter wird das dann auf jeden Fall, obs auch schneller wird ist eine andere Frage.

Speed spielt bei mir zum Glück keine Rolle. Die Festplatte ist noch extrem langsamer.

[eber]

....

Will nun ein Programm 1 Byte Speicher, wird zunächst einmal ein neuer Block angefordert. Aus diesem Block werden so lange Anfragen befriedigt, bis er komplett aufgebraucht ist. Dann wird ein neuer Block angefordert.
....

Wenn ich Jag richtig verstanden habe, macht der Topf das leider nicht so. Das heißt wenn ich zweimal 20 Byte anfordere, dann werden zwei Blöcke mit jeweils 1280 Byte verbraucht,d.h. man hat 2560 Byte weniger freien Speicher.
Dein Beispiel ist eher typisch für Betriebssysteme die mit virtueller Speicherverwaltung arbeiten (können) wie z.B. Linux oder Windows.
Da dabei Daten zeitweise auf die Platte ausgelagert werden müssen, macht es Sinn als Verwaltungseinheit die Größe der Festplattensektoren als Basis zu nehmen.
Der Topf kann das aber definitiv nicht ....

Grüße

Eber

[DeadBeef]

In Echtzeitsystemen ist vom dynamischen Allokieren/Freigeben grundsätzlich abzuraten. Denn das führt in den meisten Fällen zu Speicherfragmentierung, die vom Betriebssystem nur mit zusätzlichem Zeitaufwand beseitigt werden kann. Viele Echtzeitbetriebssysteme organisieren ihren Speicher in Pools von vorallokierten Blocks mit vordefinierten Größen, um den Verwaltungsaufwand zu minimieren.

Den Wert von 1280 kann ich bestätigen, der steht so in der internen malloc() Funktion. Des weiteren scheint TAP_MemAlloc() jedes Mal vor dem Allokieren des Speichers die Garbage Collection durchzuführen (wenn ich mich nicht täusche). D.h. bei jedem Aufruf wird im Speicher aufgeräumt, auch wenn es sich nur um ein paar Blöcke von der Firmware handelt, die sich in der Zwischenzeit angesammelt haben.

Was das Zeitverhalten angeht, darf man nicht vernachlässigen, das alleine der Overhead von Funktionsaufrufen einiges an Zeit kostet. Versuch mal den gleichen Code ohne TAP_MemInfo laufen zu lassen.

[eber]

Ein Garbage Collector in der Topf-Firmware?
Ich kann mir das eigentlich nicht vorstellen und selbst eine Speicherdefragmentierung halte ich für kaum möglich.
Oder hat der Topf-MIPS tatsächlich eine MMU, um virtuelle Adressen umsetzen zu können. Ansonsten würde ja u.U. Pointer innerhalb eines Taps nach einer Defragmentierung ins Leere zeigen...

Grüße

Eber

[Jag]

Wenn ich Jag richtig verstanden habe, macht der Topf das leider nicht so. Das heißt wenn ich zweimal 20 Byte anfordere, dann werden zwei Blöcke mit jeweils 1280 Byte verbraucht,d.h. man hat 2560 Byte weniger freien Speicher.

Genau, so ist es

Was das Zeitverhalten angeht, darf man nicht vernachlässigen, das alleine der Overhead von Funktionsaufrufen einiges an Zeit kostet. Versuch mal den gleichen Code ohne TAP_MemInfo laufen zu lassen.

Habe ich schon getestet, wenn ich in der Test-Funktion das TAP_MemAlloc() durch eine Leeranweisung ersetzte ( ; ) verkürzt sich die Ausführungszeit um mehr als 95%, das heißt TAP_MemInfo und der gesamte Rest braucht die geringste Ausführungszeit, während tatsächlich TAP_MemAlloc() signifikant langsamer arbeitet!


Gruß
Jag

[ibbi]

Wenn ich Jag richtig verstanden habe, macht der Topf das leider nicht so. Das heißt wenn ich zweimal 20 Byte anfordere, dann werden zwei Blöcke mit jeweils 1280 Byte verbraucht,d.h. man hat 2560 Byte weniger freien Speicher.

Upps, tatsächlich?!

[DeadBeef]

Ein Garbage Collector in der Topf-Firmware?
Ich kann mir das eigentlich nicht vorstellen und selbst eine Speicherdefragmentierung halte ich für kaum möglich.
Oder hat der Topf-MIPS tatsächlich eine MMU, um virtuelle Adressen umsetzen zu können. Ansonsten würde ja u.U. Pointer innerhalb eines Taps nach einer Defragmentierung ins Leere zeigen...

Speicherfragmentierung ensteht jedes Mal, wenn kleinere Speicherblöcke zurückgegeben werden. Um diese zu einem großen Block zusammenzufassen, benötigt man keine virtuelle Speicherverwaltung. VR4120, auf dessen Kern der 61130A aufbaut, hat auch eine MMU, die allerdings nicht vollständig ausgereizt wird, soweit ich das beurteilen kann. Die Exceptions, die man so üblicherweise sieht, wenn man verbogene Pointer benutzt, kommen genau von dieser MMU. Andererseits kann eine voll ausgeprägte virtuelle Speicherverwaltung auch viel Zeit kosten und ist daher für Echtzeitanwendungen auf schwächeren Prozessoren nicht geeignet.

[eber]

Speicherfragmentierung ensteht jedes Mal, wenn kleinere Speicherblöcke zurückgegeben werden. Um diese zu einem großen Block zusammenzufassen, benötigt man keine virtuelle Speicherverwaltung.

Wenn zwei freigebene Speicherbereiche "nebeneinander" liegen kann die Speicherverwaltung natürlich problemlos zu einem großem freien Speicherbereich zusammenfassen.
Leider ist es aber ja nicht immer zwangsläufig der Fall:
Wenn ich 5 x Speicher a 4 KBbyte anfordere und anschließend den 2. und 4. angeforderten Bereich wieder freigebe sieht es im RAM u.U. ja so aus:
A belegt
B frei
C belegt
D frei
E belegt
Meine Frage ist jetzt, ob der Topf in der Lage ist, eine Anforderung von 8 KB (am Stück ) aus den beiden freien Bereichen B und D zu bedienen. Und da würde ich vermuten das er das nicht kann.
D.h. wenn man häufig Speicher in unterschiedlichen Größen anfordert und (nicht in umgekehrter Reihenfolge) wieder freigibt dann "zerfleddert" es einem nach und nach den Hauptspeicher. Etwas entschärft dadurch, das die kleinste Einheit wohl 1280 Bytes sind.
Wenn Jag für einzelne Events (und deren variable langer erweiterten Beschreibung) jeweils per MemAlloc speicher anfordert würde genau diese Fragmentierung auftreten.
Vermutlich nicht so wild, da die typischerweise benötigten Größen dann in Speicherbereichen zu 1x1280,2x1280 und 3x1280 umgesetzt würden. Allerdings dann mit einer ziemlichen Speicherverschwendung, da ja selten ein Event ein Vielfaches von 1280 Bytes an Speicherplatz benötigt

VR4120, auf dessen Kern der 61130A aufbaut, hat auch eine MMU, die allerdings nicht vollständig ausgereizt wird, soweit ich das beurteilen kann. Die Exceptions, die man so üblicherweise sieht, wenn man verbogene Pointer benutzt, kommen genau von dieser MMU. Andererseits kann eine voll ausgeprägte virtuelle Speicherverwaltung auch viel Zeit kosten und ist daher für Echtzeitanwendungen auf schwächeren Prozessoren nicht geeignet.

Bei Hauptspeichermangel Daten auf Platte auszulagern macht die Topf-Firmware ziemlich sicher nicht.
Für mich stellt sich die Frage, ob die von MemAlloc zurückgelieferte Adresse eine physikalische Adresse ist, oder ob diese Adresse beim Zugriff per MMU erst in eine physikalische Adresse umgesetzt wird.

Grüße

Eber

[DeJe]

Übel ist das Verhalten des Topfes in dieser Beziehung auf jeden Fall.
Da muß ich wohl mal in meinen Source-Pool schauen ob ich ein einfaches Replacement für malloc/free finde.

[Harvey]

Oh Mann - mit was Ihr euch alles rumschlagen müsst.

Vielleicht bietet sich ja die Nachbildung einer FAT24 mit einer "Sektorlänge" von 256 Bytes an.

Dann muss man zwar direkt zu Anfang immernoch massig Speicher alloziieren, aber ich schätze, das dürfte für mehr als das doppelte an Events reichen.

[DeJe]

Bei mir ist die Sache schon geklärt.
"segregated freelists" ist die Antwort. Reichlich einfach zu implementieren, gerade mal 4 Byte overhead, im Vergleich zum Topf-Alloc affenartig schnell (Faktor min. 1000 ) ...

[ibbi]

Bei mir ist die Sache schon geklärt.
"segregated freelists" ist die Antwort. Reichlich einfach zu implementieren, gerade mal 4 Byte overhead, im Vergleich zum Topf-Alloc affenartig schnell (Faktor min. 1000 ) ...

Her mit dem Link zum Nachlesen!

[onkelsam]

bringt der GCC eigentlich kein Lib mit welche malloc beinhaltet?

Gruss
sam

[DeJe]

Doch, aber genau die hat eben oben beschriebene "Problemchen".

[onkelsam]

aber er verwendet doch TAP_MemAlloc() (der API wie ich verstehe) und nicht malloc welches vielfach als c-Lib vorhanden ist.

Oder gibt es dies bei dieser Enticklungsumgebeung nicht?

[DeJe]

Die Speicherverwaltung ist für jedes System mehr oder weniger einzigartig und steckt in den Systembibliotheken. Für den Topf kannst du kein malloc aus der Linux- oder Windows-Bibliothek nutzen. Die Systembibliothek wurde (natürlich) von Topfield erstellt.
Hier zeigt sich der Nachteil das die Systembibliotheken des Topf kein open source sind (wie eigentlich laut GPL gefordert) und deshalb gibt es die Entwicklungsumgebung auch nicht mehr offiziell.

[hagge]

Hier muss ich mal kurz einhaken.

Die Speicherverwaltung ist für jedes System mehr oder weniger einzigartig und steckt in den Systembibliotheken. Für den Topf kannst du kein malloc aus der Linux- oder Windows-Bibliothek nutzen. Die Systembibliothek wurde (natürlich) von Topfield erstellt.

Soweit richtig.

Hier zeigt sich der Nachteil das die Systembibliotheken des Topf kein open source sind (wie eigentlich laut GPL gefordert) und deshalb gibt es die Entwicklungsumgebung auch nicht mehr offiziell.

Das wiederum ist allerdings nicht richtig. Die GPL verlangt keineswegs, dass die Systembibliotheken Open Source sind. Wer mit dem GCC compiliert, hat es auch gar nicht mit der GPL, sondern mit der LGPL zu tun, die weit weniger Bedingungen stellt. D.h. die Programme, die mit dem GCC compiliert werden, können sogar komplett Closed Source sein.

Das Problem ist der GCC selbst. Die GPL verlangt nämlich, dass wenn ein GPL-Programm irgendwo vertrieben wird, der Quellcode mitgegeben werden muss oder zumindest auf Anfrage rausgegeben werden muss. Und der GCC ist ein GPL-Programm, d.h. es müsste den Quelltext zu der für die Topfield-Receiver angepassten GCC-Version geben. Das will die Firma Topfield aus was für Gründen auch immer anscheinend nicht. Möglicherweise war die Anpassung eben nur ein schneller Hack und so unsauber, dass sie den Quellcode dafür nicht öffentlich zeigen wollen, bevor das nicht jemand überarbeitet hat. Möglicherweise sind es andere Gründe.

Das Problem ist also nicht die Systembibliothek, sondern der GCC selbst. Sobald Topfield den Quellcode für die GCC-Anpassungen rausrücken würde, wäre wieder alles im Lot.

Gruß,

Hagge