Welcome, Guest. Please login or register.
Did you miss your activation email?

Author Topic:  vbox non-ose und vmwareplayer mit 2.6.36-0.slh.1-aptosid-amd  (Read 15747 times)

WilhelmHH

  • Guest
vbox non-ose und vmwareplayer mit 2.6.36-0.slh.1-aptosid-amd
« Reply #30 on: 2011/02/06, 03:50:42 »
Quote from: "frankqn"
Was ist BKL?


Das fragte ich mich auch:

http://books.google.de/books?id=PAOvoVr-l74C&pg=PA206&lpg=PA206&dq=BKL+linux&source=bl&ots=cKucqEDqY0&sig=hgWb6VNz6M03q_NDg8A3XKpZ3YQ&hl=de&ei=1QlOTZHSFdO94gaj2LioCQ&sa=X&oi=book_result&ct=result&resnum=2&ved=0CC0Q6AEwAQ#v=onepage&q=BKL%20linux&f=false

Big Kernel Lock (BKL)



http://www.heise.de/open/artikel/Die-Neuerungen-von-Linux-2-6-37-1162390.html

"Die Kernbereiche des Linux-Kernels sind nun nicht mehr auf das Big Kernel Lock (BKL) angewiesen. Dabei handelt es sich um eine Locking-Technik aus den Anfangszeiten der Multiprozessor-Unterstützung von Linux, die Konflikte beim gleichzeitigen Zugriff auf zentrale Datenstrukturen im Kernel vermeidet.

Diese Locking-Technik war damals vergleichsweise einfach umsetzbar, sperrt aber subsystemübergreifend. Das hat sich bei Systemen mit vielen Prozessorkernen negativ auf die Performance ausgewirkt und kann zu langen Latenzen bei Systemaufrufen führen, die nicht nur im Echtzeit-Umfeld unerwünscht sind.

In vielen Bereichen des Kernels hatten die Entwickler das Locking bereits in den letzten Jahren verfeinert."



http://www.freiesmagazin.de/ unter "Der Januar im Kernelrückblick":

Kurz erläutert: „Locking“

Als Locking bezeichnet man eine Methode, die zeitgleiche Zugriffe auf ein Gerät oder einen Speicherplatz verhindert.
Dabei errichtet der erste Prozess, der die Ressource nutzt, eine Sperre (englisch: Lock); alle anderen Prozes- se müssen warten, bis sie wieder freigegeben wurde.
Ältere Locking-Mechanismen zeigen sich häufig sehr gierig und sperren größere Adressräume als notwendig, wodurch andere Prozesse beim Zugriff gegebenenfalls warten müssen und damit ausgebremst werden.
Die Bestrebungen laufen derzeit dahin, dass Prozesse nur den wirklich benötigten Teil einer Ressource sperren, zum Beispiel nur einen kleinen Zweig einer Struktur anstelle des ganzen Baumes.
Dabei verhindert ein Read-Lock das Bearbeiten der Ressource, erlaubt jedoch anderen Prozessen ebenfalls das Lesen und wehrt nur Versuche zum Bearbeiten ab.
Ein Write-Lock dagegen unterbindet auch Lesezugriffe, bis dass die Änderungen vollständig sind und der Lock entfernt wurde.

frankqn

  • Guest
vbox non-ose und vmwareplayer mit 2.6.36-0.slh.1-aptosid-amd
« Reply #31 on: 2011/02/06, 15:47:28 »
Quote from: "agaida"
...Warum denken alle Leute immer, dass man Kernel so oft wechseln muss, wenn man keine Probleme hat?
"Rolling Release", der Sinn von aptosid.

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
vbox non-ose und vmwareplayer mit 2.6.36-0.slh.1-aptosid-amd
« Reply #32 on: 2011/02/06, 16:09:57 »
sorry, falscher Thread
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
vbox non-ose und vmwareplayer mit 2.6.36-0.slh.1-aptosid-amd
« Reply #33 on: 2011/02/06, 16:14:59 »
Quote from: "frankqn"
Quote from: "agaida"
...Warum denken alle Leute immer, dass man Kernel so oft wechseln muss, wenn man keine Probleme hat?
"Rolling Release", der Sinn von aptosid.

Da hab ich dann wohl was falsch begriffen und schäme mich ganz doll. Ich wechsele Kernkomponenten eigentlich erst, wenn ich relativ sicher bin, keine Probleme zu bekommen. Ausnahmen bestätigen die Regel.

Rolling Release bedeutet auch nicht, auf Teufel komm raus Pakete nur deshalb zu installieren und uptodate zu halten, weil es sie gibt. Deshalb auch die in den kommenden Wochen wieder an Wichtigkeit gewinnenden Update-Warnungen.
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen

frankqn

  • Guest
vbox non-ose und vmwareplayer mit 2.6.36-0.slh.1-aptosid-amd
« Reply #34 on: 2011/02/07, 09:09:45 »
Quote from: "agaida"
Da hab ich dann wohl was falsch begriffen und schäme mich ganz doll. Ich wechsele Kernkomponenten eigentlich erst, wenn ich relativ sicher bin, keine Probleme zu bekommen. Ausnahmen bestätigen die Regel.

Rolling Release bedeutet auch nicht, auf Teufel komm raus Pakete nur deshalb zu installieren und uptodate zu halten, weil es sie gibt. Deshalb auch die in den kommenden Wochen wieder an Wichtigkeit gewinnenden Update-Warnungen.
Du brauchst dich nicht gleich schämen. Du kannst aber auch in deiner "Ecke" stehenbleiben, wenn du magst. Das bringt mich beim aktuellen Problem zwar keinen Schritt weiter, stört mich aber auch nicht sonderlich.

Um Kernel-Updates zu verhindern, muss ich (auch nach einer frischen Installation) ins System eingreifen. Also ist es doch der aptosid-Philosophie entsprechend so gewollt, dass ich den Kernel aktuell halte.

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
vbox non-ose und vmwareplayer mit 2.6.36-0.slh.1-aptosid-amd
« Reply #35 on: 2011/02/07, 09:31:13 »
Das erste, was ich bei Arch gelernt habe, waren 2 Sachen:

* Mach nie ein Update ohne vorherige Sicherung, wenn Du Dir nicht sicher bist, dass Du die Auswirkungen ohne Neuinstallation beheben kannst.

* Auch wenn alle Leute jubeln, dass bestimmte Pakete endlich verfügbar sind - glaube nicht, dass sie deshalb funktionieren. Im Zweifel mache sie fest und verweigere Dich allen Aktualisierungen, die darauf aufbauen. Lass einfach mal andere in die braune Masse greifen ;)

Ich gebe auch zu, dass Pakete pinnen bei Arch einfacher ist, als bei debian, das ist (wie eigentlich fast alles im Paketmanagement) eine Wissenschaft für sich, die erst mal begriffen werden muss. Hilft aber ungeheuer weiter und belohnt einen mit einem stressfreien Leben. Wenn mir das zu blöd wird, bekommt das betreffende Paket halt eine eigene Revision von mir, dann hat sichs mit dem Pinnen.

Klar soll alles so aktuell sein, wie sinnvoll machbar ist. Das darf aber auf keinen Fall auf Kosten der Benutzbarkeit und Stabilität des Systems gehen (ausser, es ist einem egal oder bei Entwicklern auch gewollt - dann gelten andere Regeln)

Letztes aktuelles Beispiel ist nach dem X-Server der für die meisten hier unwichtige, weil unbenutzbare fglrx. Gestern von mir gefixt und gebaut kommt das Ding ohne funktionale Änderung, dafür aber mit höherer Revision in Sid an. Bei der geringen Bedeutung von proprietären Treibern für debian ein an ein Wunder grenzender Vorgang. Leider mit den selben falschen Abhängigkeiten wie in experimental. 2 Möglichkeiten - pinnen oder ein non-Maintainer update. Ich habe in diesem Fall Variante 2 bevorzugt und meinem Build .1 angefügt. Fall gegessen. Aktuell, so es sich nur in einer Nummer ausdrückt, muss nicht immer gut sein.

Auf jeden Fall ist in den kommenden Tagen und Wochen für Spass, Abwechslung und Frohsinn gesorgt. Langweilig wird es auch nicht, es gibt genug, was zerstört werden kann. Da braucht sich eigentlich keiner besonders anstrengen  :lol:
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen