[Mplayer-felhasznalok] 2.5-os kernel

[Toth Csaba]

Hi!

Mindenkinek ajanlom a kovetkezo riportot, ami eleg kiraly, mert technikai
reszletekbe is belemegy kicsit. A riport alanya Ingo Molnar. Talan ert egy
kevesket az utemezeshez.

http://kerneltrap.org/node.php?id=517

On Wed, 18 Dec 2002, Arpi wrote:

> > Ami biztos, hogy 2.4-es kernellel ha mondjuk lejátszás közben olyan weboldalra 
> > tévedek, amin van 1-2 procizabáló flash, akkor kicsit beszaggat a lejátszás. 
> > .gy sejtem, hogy jobb a devel kernelfában a scheduler, meg ilyenek, és 
> > remélem, hogy ezen ez segíthet. Igaz ez?

Interaktiv taszkokon segit.

"The end result is: interactive tasks are still snappy under heavy load,
and CPU-intensive tasks are isolated from interactive tasks much better
so that they cannot monopolize CPU resources."

> allitolag jobb.
> mondjuk nem vagyok tul nepszeru azzal a velemenyemmel, hogy M. Ingo O(1)
> patch-e csak cosmetics. 

Hat azt el hiszem hogy nem vagy nepszeru. Ugyanis a "cosmetics" kifelyezes
valami olyasmire utalhat, hogy nincs lenyegi valtozas, csak a kulson
valtoztatunk, nem lenyeges dolog. Ami hat khmmm... kicsit nem igaz.

> persze lehet csinalni olyan teszteket amik akar 200%
> gyorsulast is mutatnak, de a gyakorlatban nem segit, sot...

A scheduler O(1), az ujrautemezes nem fugg a processz szamtol. A regi
O(n)-es volt. Persze konkret esetben vannak szorzotenyezok. Tehat teszem
azt 20 processz eseten, lehet, hogy

beta * 1 > alfa * n

A beta faktort nyilvan le fogjak vinni a scheduler parametereinek
finomhangolasaval olyan szintre, hogy azert megerje az uj cuccos.

> ami a 2.5-ben jobb (lesz, nemtom hogy mar beraktak-e) az a thread (szal)
> valtas. ennek semmi koze a processzek kozti valtashoz.
> ergo ez sem segit rajtad.

A VM is O(1)-es lesz. Nemreg mergel-tek.

> rajtad ami segitene, az a 'nice' parancs...
> (ergo adj az mplayernek nagyobb prioritast mint a flash-nak)

A riportban is ezt ajanlja Ingo: "well, there's one area where difference 
can be felt - nice levels (priorities) are taken far more seriously in
the new scheduler. So if one wants maximum X performance even during
heavy X load which makes X a "CPU hog", the X server should be reniced to 
nice levels -10 or -15"

De olvasd el a SCHED_BATCH-rol irtakat is, mert az igazan jol johet egyik
oldalrol az mplayernek, mert az elegge CPU intenziv.

> > A másik amit nem értek, (de sajnos nem találom az urlt, így lehet, hogy csak 
> > az emlékeim csalnak meg, és tök hülyeségre emléxem). Szóval úgy rémlik, h 
> > .rpi azt írta valahol, hogy a 2.5-ben 1000Hz-cel vált taskot és hogy az 
> > mplayer meg intenzíven tudja használni a CACHE-t, és hogy taskváltáskor a 
> > cache törlődik. Jól gondolom akkor, hogy ha 10x gyakrabban vált taskot az OS, 
> > akkor a cache sokkal kevésbé hasznosítható, mint a ritkábban váltó esetben? 
> > Mivel pedig a memoria sokkal lassabb mint a cache, így a gyakori váltás 
> > valójában lassulást is okozhat (extrém esetben)?

Nemcsak jol gondolod. Ez igy van. A megoldas a SCHED_BATCH:

"another property of SCHED_BATCH scheduling is the use of much longer
timeslices. Eg. right now it's 3 seconds for a default priority
SCHED_BATCH task - while normal tasks have 150 msec timeslices. For
things like numeric calculations it's good to have as long timeslices as
possible, to minimize the effect of cache trashing. Eg. on a sufficiently 
powerful CPU with a 2 MB L2 cache, the 'population time' of the cache can 
be as high as 10 milliseconds. So if there are two numeric calculation
tasks that both fully utilize the L2 cache (in nonobvious patterns), and
which context-switch every 150 milliseconds, then they will waste 10
milliseconds on cache-rebuilding in the first 6% of their timeslice. This 
shows up as a direct 6% slowdown of the numeric calculation jobs. Now, if 
SCHED_BATCH is used, and each task has a 3000 milliseconds timeslice,
then the cache-rebuild overhead can be at most 0.3% - a far more
acceptable number."

Olvassatok el a riportot, nagyon jo!

Udv.

--

tocsa

 -----------------------------------------------
| email:     tocsa at inf.bme.hu                   |
| homepage:  http://www.inf.bme.hu/~tocsa       |
 -----------------------------------------------