Programme starten subjektiv wesentlich langsamer als unter Linux

[Kamikaze]

Ich habe mal mit dem Entwickler von gsched einen Mail-Austausch, was ein guter Weg ist gsched beim Boot zu aktivieren. Momentan mache ich das tatsächlich von /etc/rc.local aus.

Meine Schluss daraus ist, dass die Information direkt auf dem Datenträger liegen sollte (also, dass gsched erwünscht ist und welcher Algorithmus verwendet werden soll). Denn nur dort kann man unmissverständlich den zur Hardware passenden Algorithmus ablegen. Nur implementieren müsste es jemand.

Ich habe inzwischen genug im geom-Code gewühlt (wegen automounter) um das zu machen aber pkg_upgrade ist immer noch nicht fertig.

[Columbo0815]

Zitat von Kamikaze

aber pkg_upgrade ist immer noch nicht fertig.

... und dabei warte ich so sehnsüchtig darauf!

[Kamikaze]

Ich kann dir verraten, dass es auf jeden Fall deutlich schneller ist.

Hast du mal mit der aktuellen Version ein pkg_upgrade -ncfrRrR www/firefox probiert? Bei mir dauert das Preprocessing da über 6 Minuten.

Die Entwicklerversion macht das komplette Preprocessing (Abhängigkeiten auflösen, sortieren) in deutlich unter 2 Minuten.

Der Hintergrund-Downloader ist auch deutlich cleverer geworden und scheint hervorragend zu funktionieren. ...

Naja, ich hebe mir das für den Vortrag auf. Vielleicht schaffe ich ja noch rechtzeitig etwas für den FreeBSD Status Report rauszuhauen.

[Columbo0815]

Ok... ich will ja das Programm aber "aus einem anderen Grund" nutzen

[Kamikaze]

Wird schon, uma erkennt jetzt automatisch, wenn PACKAGESITE auf einen lokalen Ordner zeigt, dann zeigen PKG_INDEX, PKG_MOVED und PKG_UPDATING direkt ins lokale repository und werden nicht mehr heruntergeladen.

Auch PACKAGESITE_MIRRORS bleibt dann leer. Auch wenn man PACKAGESITE_MIRRORS leer definiert, wird das von uma nicht mehr mit den Standardmirrors aufgefüllt. pkg_upgrade hat den nötigen Read-only Support für lokale Repositories (es versucht nicht herunterzuladen, wenn die Pakete da sind und die Abhängigkeiten in den Paketen zum INDEX passen).

Was noch fehlt ist das Tool zum INDEX generieren.

[Morfio]

@Kamikaze Welcher Vortrag denn?

[h^2]

Gerade bei KDE-Programmen könnte auch relevant sein, dass sie kein Speicher teilen können und deswegen viel verschwenden. Dazu vor kurzem auf kde-freebsd@

At Thu, 09 Sep 2010 17:06:47 +0300,
Andriy Gapon wrote:
>
>
> I've just upgraded to kde-4.5.1 and during startup it spits out a lot of messages
> like the following:
>
> KSharedDataCache::Private::mapSharedMemory: Failed to establish shared memory
> mapping, will fallback to private memory -- memory usage will increase
>
> Is this something to worry about?
> What causes these messages? Perhaps some local misconfiguration on my part?

KSharedDataCache has been mostly rewritten for the 4.5 release, and
the new code relies on _POSIX_THREAD_PROCESS_SHARED being correctly
defined and implemented, which is not the case on FreeBSD.

Alberto Villa (xzhayon) was interested in working on that in a few
weeks time, but any help from the core team wrt implementing this part
of pthreads would be really appreciated.

Und dann kurz darauf schon die gute Nachricht, dass etwas mit Semaphoren implmentiert wurde:

ok, i had the patch committed in rev. 1181777. i'll wait for another
modification to make it into svn, then i'll patch kdelibs 4.5.2

unfortunately that will work only with 9-current, so i'll also write a
temporary hackish implementation for 7 and 8 users

[teuk]

Hi,

koennten die Leute, die gsched im (Dauer)einsatz haben, hier evtl. kurz Feedback geben. Mich stoert die diskutierte Zaehheit naemlich auch ein wenig. Bis auf Kamikazes Post, aus dem ich auf dauerhaften Einsatz schliessen kann(?), kann ich aus den anderen Antworten nur "mal getestet" und "herum experimentiert" heraus lesen.
Konkret interssiert mich, ob man gsched schon produktiv einsetzen kann ohne dabei Angst um seine Daten haben zu muessen (ist ja erst neu in 8.1)?. Kann ich das auch mal eben einfach so mitten im Betrieb an- und ausschalten, wie es die Manpage suggeriert? Oder doch nur lieber beim Booten? In beiden Faellen habe ich ja keine direkte Kontrolle mehr darauf, was und wieviel alles an die Platte geschickt wird und sehe also, ganz naiv betrachtet, erstmal keinen Unterschied zwischen den beiden Szenarien.

Speziell @Kamikaze: Kam bei dem erwaehnten Mail-Austausch evlt. auch noch etwas mehr zu dem Thema "geom_sched influence on SU consistency", das du vor einer Weile mal auf stable@ angesprochen hast, rum?

teuk

[Fusselbär]

Zitat von teuk

Hi,

koennten die Leute, die gsched im (Dauer)einsatz haben, hier evtl. kurz Feedback geben.

Ich habe gsched ja gestern Abend das erste mal aktiviert, Dauereinstatz wäre also übertrieben, aber seitdem lasse ich gsched laufen.
Mir ist aufgefallen, dass mein System beim locate Datenbank aufbauen geschmeidiger lief.

In der /etc/sysctl.conf habe ich das schon länger drin, was Yamagi weiter oben erwähnte:

# For AHCI and NCQ
vfs.read_max=32
# More memory for dirhashes
vfs.ufs.dirhash_maxmem=134217728

Beim benutzen von rm mit dem P Schalter für viele große Dateien scheint gsched auch für verbesserte Geschmeidigkeit zu sorgen.

[Kamikaze]

Zitat von teuk

Speziell @Kamikaze: Kam bei dem erwaehnten Mail-Austausch evlt. auch noch etwas mehr zu dem Thema "geom_sched influence on SU consistency", das du vor einer Weile mal auf stable@ angesprochen hast, rum?

Ja, da kam noch etwas bei rum.

Gsched lügt nicht über erfolgte Writes, also wird die SU Konsistenz auch nicht unterwandert.

Ich habe die Sache auch mal intensiver gestestet, gsched auf einen USB-Stick losgelassen und den im gemounteten Zustand abgezogen. Sogar das ging. Danach habe ich das beim Schreiben einer Datei wiederholt, hat das System auch nicht in eine Panic gerissen. Das Dateisystem brauchte natürlich ein fsck, aber sonst war es in Ordnung.

Und ja, ich habe das auf allen meinen Rechnern im Dauereinsatz, allerdings nur bei den fest eingebauten Platten.

[teuk]

Danke euch beiden. Das klingt ja schon mal vielversprechend - insbesondere die SU Consistency Sache. Werde das (nach dem naechten planmaessigen Backup) auch mal testen und gucken wie/ob sich gsched auf meine Use-Cases auswirkt.