CPU-Last des X-Servers bei vdpau

Hi,

ich verwende für meinen Vdr xineliboutput und vdpau für die Ausgabe. Da der Vdr nur für TV verwendet wird, habe ich mir eine vollständige X-Server-Installation (Desktop, Fenster-Manager, ..) gespart. Ich verwende eine Text-Mode-Suse-Installation und starte den nackten X-Server einfach aus der runvdr heraus. Das funktioniert auch problemlos. Nur konsumiert der X-Server dann die komplette CPU-Leistung. Starte ich den Vdr inklusive X-Server neu, benötigt der X-Server nur noch ca. 5% der CPU-Leistung. Ein einfaches Starten-Anhalten-Neustarten des X-Servers vor dem Starten des Vdr hilft nicht.

Was kann ich tun, damit der X-Server beim ersten Start sofort genügsam ist?

Gruß
e9hack

Zitat

Original von e9hack
Was kann ich tun, damit der X-Server beim ersten Start sofort genügsam ist?

Wenn man beim Starten vom X-Server Display und Terminal mit angibt, startet der Server gleich ohne großen Load.

Gruß
e9hack

Zitat

Original von sparkie
was bedeutet das genau: 'beim Starten vom X-Server Display und Terminal mit angibt'?

Bisher habe ich den X-Server so gestartet:

exec /usr/bin/X &>/dev/NULL &

Jetzt so:

exec /usr/bin/X :0 vt7 &>/dev/NULL &

Warum der ohne Display und Terminal mehr oder weniger die verfügbare CPU Leistung auffrißt, ist mir unklar.

Zitat

Oder hat suse wieder mal eine Sonderlocke gestrickt:)

Ich verwende das Suse-X-Server-Zeug nicht. Da wird soviel gestartet, daß es 1min länger dauert, bis ich ein Bild habe.

Gruß
e9hack

Zitat

Original von sparkie
sehr merkwuerdig. Das macht bei mir auf debian squeeze keinen Unterschied. Vielleicht gibt ein 'strace' einen Hinweis, warum er im Fehlerfall so busy ist?

Wenn der X-Server busy ist, liefert strace sowas:

setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0
clock_gettime(CLOCK_MONOTONIC, {140, 97776509}) = 0
clock_gettime(CLOCK_MONOTONIC, {140, 97805001}) = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
select(256, [1 3 4 6 8 14 15 16 17 18 21 25 31], NULL, NULL, {1094, 401000}) = 1 (in [6], left {1094, 400994})
ioctl(6, TCFLSH, 0x2)                   = -1 EIO (Input/output error)
setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0
clock_gettime(CLOCK_MONOTONIC, {140, 98025952}) = 0
clock_gettime(CLOCK_MONOTONIC, {140, 98054444}) = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
select(256, [1 3 4 6 8 14 15 16 17 18 21 25 31], NULL, NULL, {1094, 400000}) = 1 (in [6], left {1094, 399993})
ioctl(6, TCFLSH, 0x2)                   = -1 EIO (Input/output error)
setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0
clock_gettime(CLOCK_MONOTONIC, {140, 98262546}) = 0
clock_gettime(CLOCK_MONOTONIC, {140, 98291038}) = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
select(256, [1 3 4 6 8 14 15 16 17 18 21 25 31], NULL, NULL, {1094, 400000}) = 1 (in [6], left {1094, 399994})
ioctl(6, TCFLSH, 0x2)                   = -1 EIO (Input/output error)

Das wiederholt sich permanent. Innerhalb von 30sec ist das Log ca. 5MByte groß geworden.

Wenn alles OK ist gibts nur wenige Zeilen:

select(256, [1 3 4 6 9 15 16 17 18 19 22 26 32], NULL, NULL, {1062, 111865}) = 1 (in [26], left {1041, 960976})
setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0
clock_gettime(CLOCK_MONOTONIC, {390, 578677528}) = 0
clock_gettime(CLOCK_MONOTONIC, {390, 578711604}) = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
select(256, [1 3 4 6 9 15 16 17 18 19 22 26 32], NULL, NULL, {1041, 934000}) = 1 (in [26], left {1041, 933979})
poll([{fd=26, events=POLLIN}], 1, 0)    = 1 ([{fd=26, revents=POLLIN}])
read(26, "l\4\1\1\35\0\0\0\7\0\0\0\211\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 2048) = 378
read(26, 0xb4d1f0, 2048)                = -1 EAGAIN (Resource temporarily unavailable)
setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0
clock_gettime(CLOCK_MONOTONIC, {390, 579167444}) = 0
clock_gettime(CLOCK_MONOTONIC, {390, 579197051}) = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
select(256, [1 3 4 6 9 15 16 17 18 19 22 26 32], NULL, NULL, {1041, 933000} <unfinished ...>

Das kam innerhalb von einer Minute.

Ich kann aber damit nichts anfangen.

Gruß
e9hack

Zitat

Original von sparkie
ok, man sieht aus dem gekuerzten Log leider nicht, was hinter fd 6 fuer ein Device steckt.

fd 6 bzw. jetzt 8 ist /dev/tty2.

In Xorg.0.log stand 'using VT number 2' wenn der X-Server busy war und 'using VT number 7', wenn man ihn gekillt und neu gestartet hat. Darüber bin ich auf die Parameter gekommen. Nur irgendwie hat '/usr/bin/X vt7' alleine nicht ausgereicht. Mit /usr/bin/X :0 vt7' war dann Ruhe.

Bei Suse sind auf VT1 bis 6 normale Login's. Vermutlich ist beim frühen starten von X nur VT1 aktiv. VT2 bis 6 werden erst später aktiviert. X kommt dann mit VT2 in Konflikt. Wenn man den X-Server abschießt und neu startet, sucht der sich vermutlich das nächste freie virtuele Terminal, was dann 7 ist.

Gruß
e9hack