Thread pinning... Wann?



  • Hi.

    Hat einer von Euch Erfahrung mit Thread pinning bei parallel ablaufenden Threads? Wie viel bringt so etwas und in was fuer Situationen ist es angebracht? Kann man da einen Leitfaden oder eine Art Checkliste angeben, in was fuer Faellen man da genauer gucken sollte?



  • es ist fuer situationen in denen du denkst, dass der normale OS scheduler es dynamisch schlechter macht als du es statisch machen kannst, weil du mehr ueber das program weisst, z.B. weil du weisst welcher thread der kritische ist und nicht unterbrochen werden sollte waehrend andere sie die cores teilen koennen.



  • Was ist thread pinning? Gibts dazu irgendwo brauchbare Informationen?



  • Kellerautomat schrieb:

    Was ist thread pinning? Gibts dazu irgendwo brauchbare Informationen?

    http://lmgtfy.com/?q=Thread+Pinning



  • rapso schrieb:

    es ist fuer situationen in denen du denkst, dass der normale OS scheduler es dynamisch schlechter macht als du es statisch machen kannst, weil du mehr ueber das program weisst, z.B. weil du weisst welcher thread der kritische ist und nicht unterbrochen werden sollte waehrend andere sie die cores teilen koennen.

    Dafür würde man doch eher Prioritäten verwenden.
    Pinning ist wenn man nicht möchte dass der Thread von einem Core zum anderen "wandert".
    So hab' ich das zumindest verstanden.



  • hustbaer schrieb:

    rapso schrieb:

    es ist fuer situationen in denen du denkst, dass der normale OS scheduler es dynamisch schlechter macht als du es statisch machen kannst, weil du mehr ueber das program weisst, z.B. weil du weisst welcher thread der kritische ist und nicht unterbrochen werden sollte waehrend andere sie die cores teilen koennen.

    Dafür würde man doch eher Prioritäten verwenden.

    das nehmen viele faelschlicherweise an und leider passen viele OS ihr scheduling daran an.
    Priority sollte nur sagen welcher thread am latenz kritischten ist, sollte aber nicht gleichbedeutend sein mit durchsatzkritischstem.
    es kann sein dass du 'realtime' threads hast die die meiste zeit schlafen und ab und zu aufwachen (z.b. sound, input, vsync und andere hardware callbacks), wenn du nicht moechtest, dass diese deinen durchsatzkritischen thread unterbrechen, aber dennoch weiterhin zeitkritisch abgearbeitet werden, partitionierst du die threads entsprechend durch pinning.

    Pinning ist wenn man nicht möchte dass der Thread von einem Core zum anderen "wandert".
    So hab' ich das zumindest verstanden.

    das ist die loesung, aber die frage war ja 'wofuer'? zu sagen thread pinning ist fuer thread pinning da ist...emm.. true but void.
    der punkt ist, dass du per hand die threads balanzierst, was eigentlich das OS macht, nur du es besser weisst, weil das OS nicht antizipieren kann was die 'blackbox' von dir fuer bedarf hat.
    du willst also in erster linie dass andere threads nicht deinen thread aufheben. threads die eventuell wichtiger sind als deiner auf kurze zeit gesehen, aber auf lange zeit hin nicht laufzeitentscheident sind.

    100mal die sekunde cores zu switchen ist sicherlich wenig overhead, dafuer kann man thread pinning natuerlich auch verwenden, aber das OS wird dennoch deinen thread unterbrechen und ein paar sicherheitsringe durchqueren und dein thread koennte genau so auf einem anderen core weiterlaufen.
    core switching zu verhindern fuer die eigentlichen threads aus performance gruenden wird erst sinn machen wenn du ein multi socket system hast, aber normalerweise hast du dann auch ein OS dass versucht sowohl threads als auch allokationen nah beieinander zu halten, auch hier hast du dann nur die Not thread pinning zu betreiben, wenn du es besser weisst als das OS, wobei dann das memory management weitaus mehr ausschlag gibt, normalerweise.

    wenn man threads pinnt einfach nur um gleichwertigen threads das switchen abzunehmen kann man sich damit auch schaden wenn das OS weiterhin nicht weisst welchen thread es aufheben darf. dann kommt es aber aufs OS an. in manchen kann man globale priorities setzen die sogar ueber interrupts sind und damit verschluckt man eher interrupt callbacks als das den thread zu unterbrechen und du kannst cycle genau durchlaeufe simulieren, auf windows hingegen sind die priorities eher ein hint welches budget du fuer den thread moechtest.

    wenn man mit thread pinning anfaengt, kann man weitermachen mit fibern/coroutines (oder wie auch immer man das nennen will). dann kann man einen eigenen scheduler schreiben und genau das verteilen der arbeit organisieren. man kann dann z.b. eine 8core machine mit 8 consumer und 7 producer fibern ueberladen und immer dafuer sorgen dass bei jedem "submit" bzw "consume" der hardware thread die entsprechende thread group abarbeitet, damit es keine starvation aber auch einen ueberlauf gibt. Ein OS kann das von aussen nicht sehen, es gibt dann immer verschleiss, egal wie man die prioritaeten legt und ob man 1:7, 1:8 oder 7:8 aufteilt. (angenommen man will sich thread priority switching zur laufzeit sparen, weil das overhead waere der zwar die auslastung perfektionieren kann aber der overhead mehr kosten kann als wegoptimiert wurde).


Log in to reply