FreeBSD: RELENG_5 im CVS
- Ersteller asg
- Erstellt am
i18n
Well-Known Member
So, nu isse durch:
Copyright (c) 1992-2004 The FreeBSD Project.
FreeBSD 5.3-BETA1 #0: Mon Aug 23 04:56:35 CEST 2004
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
Inwieweit ist die entfernt von 5.2?
Ich wollte mir den Weltenbau noch aufheben, bis 5.3 wirklich stable ist, mergemaster ist immer recht nervig.
PS: Gibt es eine ausführlichere Beschreibung als man mergemaster?
Copyright (c) 1992-2004 The FreeBSD Project.
FreeBSD 5.3-BETA1 #0: Mon Aug 23 04:56:35 CEST 2004
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
Inwieweit ist die entfernt von 5.2?
Ich wollte mir den Weltenbau noch aufheben, bis 5.3 wirklich stable ist, mergemaster ist immer recht nervig.
PS: Gibt es eine ausführlichere Beschreibung als man mergemaster?
Maledictus
FreeBSD ftw
Die 5.3 ist ziemlich weit weg von 5.2.1, mergemaster dauert ewig, und viele viele einzeilige Änderungen.
@asg
kann man auch alles automatisch austauschen lassen?
@asg
kann man auch alles automatisch austauschen lassen?
asg
push it, don´t hype
carbuncle schrieb:
Hier mal eine Erklärung von Wes:
Code:
In FreeBSD 3.x and 4.x, the SMP code allows user processes to run, 1 per
cpu, without contention for resources. This is only true when they are
running in "user mode", i.e. NOT making any kernel calls.
Inside the kernel, in order to make sure critical data structures get
updated atomically (read that as "all at once" if you don't speek geek), we
put a "lock" around them. Whoever has the lock is allowed to read and
write the data structure, and everyone who is waiting for the lock has to
continue to wait until the lock holder gives up the lock. This protects us
against the case where I read a value, do some calculations, and then
change the value. Other threads of execution cannot even safely read the
value if I am going to change it.
The simplified version of SMP in FreeBSD 3-4 has one lock, referred to as
the Big Giant Lock, or BGL, or just Giant. This means that any process
that makes a system call* has to take the Giant lock, or wait for it to be
released. This means the SMP goodness is not shared among processes that
do a lot of I/O -- web and ftp servers, for example -- which are really the
sweet spot of the FreeBSD server userbase.
The development thrust of FreeBSD 5 is to develop fine-grained SMP. This
means instead of one Big Giant Lock, there are more locks, which protect
individual data structures, or groups of data structures as subsystems.
This allows multiple processes to be executing kernel code simultaneously,
so long as they're not trying to execute exactly the same kernel code at
the same instant.
The advantages of this finer-grained locking is to get more parallelism in
the kernel as well. Consider a web server, where the basic job is read a
request from a socket, then send the contents of one or more files in
return. If you have two or more clients attached, and multiple processes
to serve those clients, each process can be attempting to read from the
network, write to the network, or read from the disk. Instead of one
process reading from a network socket while all the other processes wait
for it, you have one process that can complete all of the socket read right
down to the critical data structures, locking only the socket it is reading
from, while another is doing disk reads, locking only the file descriptor
it is using. (Both have to, at some time, lock the global list of sockets
and file descriptors, but only when creating or freeing these resources,
see?)
At this point in time, a few major subsystems have been removed completely
from Giant, with their own subsystem or data structure locks. Other
systems, subsystems, or even just drivers are still protected by Giant.
Understanding locking as a concept is not all that difficult. Any good
operating system textbook, or basic computer science textbook, will cover
the concept adequately. I'll go out on a limb here and recommend the uC/OS
II book as an excellent reference for both what locks do and a simple,
embraceable implmentation.
If you want to get started on "lock pushdown" in FreeBSD, a classic "Junior
Kernel Hacker" task, I'll refer you to John Baldwin <jhb@freebsd.org> for
marching orders. There are a large number of such tasks that essentially
require you to find another similar driver that has already been
de-Giantified, identify the critical data structures in the driver of
interest, and lock in a manner similar to the known good driver, then test
test test.
* This is the simplified explanation. There are some system calls that
don't have to be locked. The details aren't important to anyone who
doesn't already understand locking. ;^)
carbuncle
Rainbow Six
ok, alles zurück, war scheisse was ich hier gemacht hab.
Ich habe meine Sourcen mittels cvs aktualisiert. Danach habe ich erst den Kernel neu gebaut (MIT DER ALTEN KERNELDATEI!!!!). Danach den Kernel installiert.
danach die Welt gebaut, im Single user modus die Welt installiert.
Da ich meine alte kerneldatei genommen habe, darf ich mich natürlich nicht beschweren, wenn die module io und mem fehlen
. Naja das nächste mal mehr lesen....
carb
PS: Danke für die Beschreibung zu [GIANT_LOCKED]!!!
Ich habe meine Sourcen mittels cvs aktualisiert. Danach habe ich erst den Kernel neu gebaut (MIT DER ALTEN KERNELDATEI!!!!). Danach den Kernel installiert.
danach die Welt gebaut, im Single user modus die Welt installiert.
Da ich meine alte kerneldatei genommen habe, darf ich mich natürlich nicht beschweren, wenn die module io und mem fehlen
. Naja das nächste mal mehr lesen....carb
PS: Danke für die Beschreibung zu [GIANT_LOCKED]!!!
Stevil
Well-Known Member
wenn ihr mir hier helfen könntet.... --> http://www.bsdforen.de/showthread.php?t=5793
dann würd ich gerne bestätigen!
dann würd ich gerne bestätigen!
Maledictus
FreeBSD ftw
unter 6.0-CURRENT von Gestern läuft fluxbox top 
Maledictus
FreeBSD ftw
Ice schrieb:
fluxbox (nicht devel) und
xorg