Das längste Thema

  • Genau das was du vorher geschrieben hast - Das rumschubsen über die CPU-Kerne gibt es bei Windows schon seit Jahren nicht mehr.

    "Security is like an onion - the more you dig in the more you want to cry"

  • mainziman schwelgt halt gerne in alten Erinnerungen, anders kann ich mir den Exkurs zu WinG und Win3.1 im letzten Beitrag auch nicht erklären oder warum er immer mit so Urzeitsystemen vergangener Tage ankommt wenn er was allgemeines über den Task-Manager schreibt und dann mit WinXP ankommt. Damit rechnet man heutzutage nicht mehr ^^


    Aber wie vmk schreibt, alle Scheduler der letzten 10 Jahre (grob) können ordentlich mit HT umgehen und schieben auch keine CPU-lastigen Threads wild durch die Gegend. Sofern man ein halbwegs aktuelles OS betreibt, braucht man sich also darum keinerlei Sorgen machen 8)

  • Das rumschubsen über die CPU-Kerne gibt es bei Windows schon seit Jahren nicht mehr.

    Ach :DscreenTaskmgr.png

    der selbe CPU-lastige Prozess mit einem einzigen Thread ...


    Aber wie vmk schreibt, alle Scheduler der letzten 10 Jahre (grob) können ordentlich mit HT umgehen und schieben auch keine CPU-lastigen Threads wild durch die Gegend.

    dich hat die Vergangenheit eingeholt:D,

    es ist immer noch so ...,

    oder wie erklärst sonst obiges Bild?:/

    komm mir aber nicht des wär ein altes System :D

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • btw netcup "[…] von den den Sicherheitslücken […]"


    Falls das noch jemand ausbessern möchte, bei den letzten Foreshadow-Mails, die erst raus gehen.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • oder wie erklärst sonst obiges Bild?

    Vielleicht einfach unsauber programmiert falls es wichtig ist das der Thread auf einem Core läuft bzw. dadurch tatsächlich mehr Performance bringt :/ Windows unterstützt Core Affinitäten (SetProcessAffinityMask). die man zur Laufzeit setzten kann/soll/muss. Davon ab ist die Meinung dazu "der Scheduler weiß besser wie du was er macht, lass ihn seinen Job tun", Initial ging es auch eher darum ob es für Windows egal ist ob es ein HT-Core ist oder ein physikalischer Core, und genau darauf achtet Windows penibel (siehe Screenshot von vmk).


    Davon ab hast du bei jedem Context-Switch den Fall das die Register meist geflusht und die L1/L2-Caches nutzlos werden, da ein anderer Thread meist einen anderen Code ausführt und auf einem anderen Daten-Bereich arbeitet. Daher macht es in den meisten Fällen wohl keinen großen Unterschied wenn der Kern getauscht wird (L3-Cache ist ja noch da), und da wo es wirklich einen macht kann der Programmierer das entsprechend mitteilen. Außer man teilt dem System explizit mit auf einem Kern nur einen Thread laufen zu lassen. Das kann der Scheduler aber schwer entscheiden, da er ja nicht weiß wie viel CPU der Thread im nächsten bzw. aktuellen Zyklus brauchen wird. Von daher wird erst mal alles "nach Prioritäten" verteilt, sodass jeder irgendwie irgendwann dran kommt. Jedem Thread der mal etwas CPU gebraucht hat direkt einen kompletten Core zu reservieren kann wohl schnell nach hinten losgehen, gerade unter Windows wo im Hintergrund unzählige Threads laufen die gerne auch mal etwas mehr CPU fressen, da will man nicht das die alle einen Core blockieren.

    Falls es wirklich Sinn macht (und die Workload ist wohl eher selten, auf einem fetten Multicore System einen fetten Single-Thread Task laufen zu lassen) muss man dies halt von Hand festlegen, bzw einfach die CPU-Affinität so setzten das der Thread nur auf einem Kern laufen darf. Das ist bei dir wohl schlichtweg nicht der Fall.


    Das ganze ist auch in Wiki schön erklärt: https://en.wikipedia.org/wiki/Processor_affinity


    Wichtig ist aber das wenn 4 Cores (bei einer 4-Core CPU => 8HT-Core CPU) die mit 4 Threads zu 100% belastet wird, diese 4 Threads alle auf physikalischen Kernen laufen und nicht zwei zusammen auf einem HT-Core und das klappt so auch (siehe Screenshot vmk) 8)


    https://serverfault.com/questi…balanced-across-cpu-cores

    https://superuser.com/question…thread-spread-across-cpus

    https://docs.microsoft.com/en-…hread/multiple-processors


    dich hat die Vergangenheit eingeholt,


    Das bezweifel ich, ich komme hier nicht direkt mit Win3.11, DOS oder sonstwas an wenn mir etwas nicht passt bzw ich was als "nicht state-of-the-art" darstellen will :P Und wie du bei vmk siehst wird da nix wild durch die Gegend geschoben.Was du immer hier an Sonderfälle ranpackst wird es immer geben, dafür sind Systeme zu vielfältig, du findest sicher auch irgendein Exoten-OS wo heutzutage nicht mit HT umgehen kann.


    Edit: das virtuelle hab ich auch überlesen, da der Scheduler dadurch keinerlei Informationen über CPU-Aufbau oder ähnliches hat (er kennt nicht mal den L1-Cache), ist das natürlich alles hinfällig und er "ignoriert" die Hardware, was will er auch sonst machen er weiß ja nichts über die Hardware ^^

  • julian-w Multi-Threaded-Programme sollen SetThreadAffinityMask verwenden; SetProcessAffinityMask setzt dies f. alle Threads eines Prozesses;

    diese sind dann aber was die Verwendbarkeit auf anderen System angeht eingeschränkt;


    das 'virtuell' hat hier gar keine Relevanz, im Gegenteil: hier hat Win10 gröbere Bugs;

    ich empfehle das hier

    https://docs.microsoft.com/en-…ernals/downloads/coreinfo

    damit wird in der VM sehr wohl die Info zum Cache und so angezeigt,

    es werden damit 8 physikalische Einzel-CPUs angezeigt an Stelle von einer CPU mit 8 Cores (4 HT Cores)



    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • damit wird in der VM sehr wohl die Info zum Cache und so angezeigt,

    Bei dir im Screenshot sehe ich nur "nicht zutreffend" (ich vermute mal das soll es heißen). Von daher werden die Infos wohl nicht ganz korrekt angezeigt an der Stelle wo sie es sollten.

    es werden damit 8 physikalische Einzel-CPUs angezeigt an Stelle von einer CPU mit 8 Cores (4 HT Cores)

    Das klingt aber eher so als ob die Virtualisierung da was nicht ganz durchgibt. Ich kenne dein Setup nicht, von daher kann ich nichts weiter dazu sagen zu deinem Test. Nur soviel: von sich aus wird qemu/KVM oder sonstige Virtualisierungslösungen wie VirtualBox keine HT-Cores als "HT-Cores" durchreichen. Schon nur weil du mehr CPUs simulieren kannst wie der Host hast oder auch weniger durchreichst. Der Scheduler ändert dann je nachdem noch den Core und schwupp macht eine (automatische) Zuordnung keinen Sinn, und on-the-fly dem Gast die CPUs ändern ist eher eine schlechte Idee. Wenn man das ganze manuell per Hand einrichtet (CPU Pinning etc.) dann mag es möglich sein, weiß ich aber nicht. Bei VirtualBox hab ich noch nie eine Funktion zum anlegen von HT-Cores gesehen.


    Von daher hättest du am besten die Ausgabe von Coreinfo gepostet, so ist das nur ein rätselraten was Windows hier erkennt, laut Screenshot nichts korrektes.

    julian-w Multi-Threaded-Programme sollen SetThreadAffinityMask verwenden; SetProcessAffinityMask setzt dies f. alle Threads eines Prozesses;

    diese sind dann aber was die Verwendbarkeit auf anderen System angeht eingeschränkt;

    In deinem Beispiel ging es doch um Single-Thread Last oder täusche ich mich da? Von daher passt das doch (bzw. würde beides passen).

  • julian-w nein Du täuscht Dich nicht, es geht um Single-Thread Last;


    so sieht die Definition der CPUs am Host f. die VM aus

    screenCPUs.png


    am Host sieht coreinfo so aus


    in der VM sieht coreinfo so aus

    hier 'nicht zutref.' bei L1 Cache anzuzeigen ist ein Bug im Win10 Task-Manager

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • so sieht die Definition der CPUs am Host f. die VM aus

    Um welche Software zur Virtualisierung handelt es sich denn hierbei? Das sieht irgendwie nach WinXP oder davor aus, also eine ältere Software? Oder benutzt du nur gerne den alten Stil unter Windows ^^


    Und das der Gast keine HT-Cores sieht ist doch logisch, es sind ja schließlich keine eingestellt im Hypervisor soweit man das dem Screenshot entnehmen kann.


    Aber irgendwie passen deine Coreinfo ausgaben überhaupt nicht, hier das ganze unter Windows 10 x64 mit einem Core i5-4771 (4 Kerne + HT):


    So in etwa sollte das bei jedem Core iX-XXXX aussehen der Hyperthreading unterstützt. Bei dir sieht es halt komplett anders aus.


    Am Host sind die Caches nicht korrekt zugeordnet, zu den CPUs gibt es gar keine Infos, und im Gast kommt eh nur noch einzelne Dinge an. Kein Wunder das der Task-Manager da keinen korrekten Wert finden kann. Irgendwas läuft da schief bei dir :/


    Edit: Dein Host meint das alle Caches von allen CPU-Kernen direkt zugegriffen werden können, daher kann der auch munter Threads zwischen den CPU-Kernen verschieben ^^ Und laut Dump hast du nur einen physikalischen Kern der 8 Hyper-Threading Kerne simuliert oder sowas in der Art...

  • Gibt's jemanden, der noch gar keine Mail wegen den Foreshadow-Restarts bekommen hat, oder bin ich alleine? :D (hab 17 Server hier und will nicht, dass die alle gleichzeitig dran sind :D )

    Habe aktuell "nur" noch 6 Server bei NetCup, aber heute gegen 18.30 die erste Mail (für den 31.8. 10-12 Uhr) bekommen. :)

    Meine Minecraft-Plugins auf SpigotMC (Open Source): www.spigotmc.org/members/mfnalex.175238/#resources

    Discord: discord.jeff-media.com

  • Ich habe auch erst heute um 18:25 eine Mail erhalten, für einen 201807.


    Noch ausstehend sind 201708, 201612 und 201609.


    Keine Ahnung, welche Logik die Reihenfolge hat.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)