Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Mocno ludziska sie podniecaja nowym paczem co daje niezlego kopa w wydajnosci:
http://www.phoronix.com/scan.php?page=article&i … deo&num=1
Jak ktos testowal niech sie podzieli opiniami.
Offline
W kernelu 2.6.38 ma być, poczekamy to każdy będzie mógł sprawdzić.
Offline
Że tak nieśmiało spytam... A ta łatka co zmieniała jakąś tam ziarnistość w jądrze to jest już w jądrze? Bo jeśli jest to zmian nie zauważyłem, stąd moje wątpliwości czy faktycznie odczujemy wpływ tejże nowej łatki.
Offline
debianus_userus napisał(-a):
Jak ktos testowal niech sie podzieli opiniami.
/me testuje... działa :) Znaczy system na 2.6.37-rc2 z tym patchem chodzi płynniej i jest bardziej responsywny pod obciążeniem, niż na 2.6.36 z patchsetem Cona Kolivasa (zawierającym BFS). Więcej pewnie się pobawię jutro (tudzież dzisiaj, ale później), bo szczerze mówiąc teraz już mi się nie chce :P
PS Nvidia z repo experimental kompiluje się i działa na jaju 2.6.37-rc2, gdyby ktoś się zastanawiał :)
Offline
No to jeszcze przetestuj na 2.6.36, bo mi się nie chce.
http://marc.info/?l=linux-kernel&m=128747979529320&w=2
byś szukać już nie musiał ;)
Ostatnio edytowany przez raven18 (2010-11-17 08:09:27)
Offline
W Liquorixie wkompilowana jest ta opcja:
CONFIG_SCHED_AUTOGROUP=y
Offline
Offline
Warto jeszcze spojrzeć na to:
http://www.webupd8.org/2010/11/alternative-to-200-l … el-patch.html
I post źródłowy: http://lkml.org/lkml/2010/11/16/392
Offline
Łata na 2.6.36: http://marc.info/?l=linux-kernel&m=128948923601573&w=2
U mnie wchodzi nieźle:
root linux-2.6.36-gentoo # patch -p1 --dry-run <2236.patch patching file include/linux/sched.h patching file kernel/sched.c patching file drivers/char/tty_io.c patching file kernel/exit.c patching file kernel/sched_autogroup.h patching file kernel/sched_autogroup.c patching file kernel/sysctl.c Hunk #1 succeeded at 398 (offset 14 lines). patching file init/Kconfig patching file Documentation/kernel-parameters.txt
// przeniosłem do wątku o tym "cudzie" — ArnVaker
Ostatnio edytowany przez Jacekalex (2011-03-11 11:42:57)
Offline
Minio napisał(-a):
Warto jeszcze spojrzeć na to:
http://www.webupd8.org/2010/11/alternative-to-200-l … el-patch.html
I post źródłowy: http://lkml.org/lkml/2010/11/16/392
Próbowałem - nie widzę ŻADNEJ różnicy w działaniu systemu (8-letni komputer).
Offline
A ja mam przed nosem 2.6.37-rc3 i widzę jedną różnicę: nieco mniejsze obciążenie procka, aniżeli na 2.6.36-gentoo (konfig ten sam).
Różnica - na oko (dziad w szpitalu umarł ;)) 5 - 10% mniej.
Natomiast sama łata na 99% blokuje działanie serwera jack-audio.
Edyta:
już jacka nie blokuje, trzeba było tylko przekopać konfig i wyłączyć parę rzeczy.
Ostatnio edytowany przez Jacekalex (2010-11-23 09:25:45)
Offline
Tak odnośnie obciążenia procka... nie wiem czy to jakiś błąd ale na >= 2.6.35 obciążenie procka przy tych samych operacjach mam zdecydowanie większe niż na 2.6.34 a co z tym idzie... podgrzewa mi rączki na klawiaturze... już jest zimno więc może wie co robi ;-))
Offline
ArnVaker napisał(-a):
W waniliowym 37 jeszcze nie ma, dopiero w 38 jest w mainline.
Ostatnio jak nakładałem to z palca na 37, wziąłem patcha dokładnie stąd: https://lkml.org/lkml/2010/11/30/121
Obecnie używam tego patchsetu (opcja 2 — bez kztmem) i tam już jest: http://forums.gentoo.org/viewtopic-t-862105.html
Ja sobie nałożyłem tego patcha :)
Nawet z ciekawości, bo nigdy czegoś takiego nie robiłem. Tak to się robi?
gentoo linux # patch -p1 < /home/marg1/1_btrfs-2.6.38-rc4.patch patching file fs/btrfs/Kconfig patching file fs/btrfs/Makefile patching file fs/btrfs/acl.c patching file fs/btrfs/btrfs_inode.h patching file fs/btrfs/compression.c patching file fs/btrfs/compression.h patching file fs/btrfs/ctree.c patching file fs/btrfs/ctree.h Hunk #5 succeeded at 908 (offset -2 lines). Hunk #6 succeeded at 1064 (offset -2 lines). Hunk #7 succeeded at 2162 (offset -7 lines). Hunk #8 succeeded at 2206 (offset -7 lines). Hunk #9 succeeded at 2565 (offset -7 lines). patching file fs/btrfs/disk-io.c Hunk #10 succeeded at 2454 (offset -11 lines). Hunk #11 succeeded at 2479 (offset -11 lines). Hunk #12 succeeded at 2559 (offset -11 lines). Hunk #13 succeeded at 2678 (offset -11 lines). patching file fs/btrfs/disk-io.h patching file fs/btrfs/export.c patching file fs/btrfs/extent-tree.c Hunk #3 succeeded at 3086 (offset -1 lines). Hunk #4 succeeded at 3158 (offset -1 lines). Hunk #5 succeeded at 3174 (offset -1 lines). Hunk #6 succeeded at 3341 (offset -1 lines). Hunk #7 succeeded at 3357 (offset -1 lines). Hunk #8 succeeded at 3365 (offset -1 lines). Hunk #9 succeeded at 3381 (offset -1 lines). Hunk #10 succeeded at 3596 (offset -1 lines). Hunk #11 succeeded at 3746 (offset -1 lines). Hunk #12 succeeded at 4032 (offset -1 lines). Hunk #13 succeeded at 5654 (offset -1 lines). Hunk #14 succeeded at 5662 (offset -1 lines). Hunk #15 succeeded at 6268 (offset -1 lines). Hunk #16 succeeded at 6367 (offset -1 lines). Hunk #17 succeeded at 6496 (offset -1 lines). Hunk #18 succeeded at 7529 (offset -1 lines). Hunk #19 succeeded at 7587 (offset -1 lines). Hunk #20 succeeded at 7831 (offset -1 lines). Hunk #21 succeeded at 8022 (offset -1 lines). Hunk #22 succeeded at 8065 (offset -1 lines). Hunk #23 succeeded at 8201 (offset -1 lines). Hunk #24 succeeded at 8209 (offset -1 lines). Hunk #25 succeeded at 8322 (offset -1 lines). Hunk #26 succeeded at 8444 (offset -1 lines). Hunk #27 succeeded at 8458 (offset -1 lines). Hunk #28 succeeded at 8705 (offset -1 lines). patching file fs/btrfs/extent_io.c patching file fs/btrfs/extent_io.h patching file fs/btrfs/extent_map.c patching file fs/btrfs/extent_map.h patching file fs/btrfs/file-item.c patching file fs/btrfs/file.c patching file fs/btrfs/free-space-cache.c patching file fs/btrfs/inode.c Hunk #28 succeeded at 4138 (offset -4 lines). Hunk #29 succeeded at 4351 (offset -4 lines). Hunk #30 succeeded at 4378 (offset -4 lines). Hunk #31 succeeded at 4954 (offset -4 lines). Hunk #32 succeeded at 4967 (offset -4 lines). Hunk #33 succeeded at 5010 (offset -4 lines). Hunk #34 succeeded at 5069 (offset -4 lines). Hunk #35 succeeded at 5115 (offset -4 lines). Hunk #36 succeeded at 5151 (offset -4 lines). Hunk #37 succeeded at 5183 (offset -4 lines). Hunk #38 succeeded at 5289 (offset -4 lines). Hunk #39 succeeded at 5514 (offset -4 lines). Hunk #40 succeeded at 5649 (offset -4 lines). Hunk #41 succeeded at 6510 (offset -4 lines). patching file fs/btrfs/ioctl.c Hunk #1 succeeded at 200 (offset -3 lines). Hunk #2 succeeded at 638 (offset -5 lines). Hunk #3 succeeded at 650 (offset -5 lines). Hunk #4 succeeded at 693 (offset -5 lines). Hunk #5 succeeded at 791 (offset -5 lines). Hunk #6 succeeded at 902 (offset -5 lines). Hunk #7 succeeded at 1809 (offset -93 lines). Hunk #8 succeeded at 1992 (offset -97 lines). Hunk #9 succeeded at 2048 (offset -97 lines). Hunk #10 succeeded at 2244 (offset -97 lines). patching file fs/btrfs/ioctl.h Hunk #1 succeeded at 133 (offset -1 lines). patching file fs/btrfs/lzo.c patching file fs/btrfs/ordered-data.c patching file fs/btrfs/ordered-data.h patching file fs/btrfs/print-tree.c patching file fs/btrfs/relocation.c patching file fs/btrfs/super.c Hunk #11 succeeded at 863 (offset -3 lines). Hunk #12 succeeded at 991 (offset -3 lines). Hunk #13 succeeded at 1013 (offset -3 lines). Hunk #14 succeeded at 1140 (offset -2 lines). Hunk #15 succeeded at 1175 (offset -2 lines). Hunk #16 succeeded at 1191 (offset -2 lines). patching file fs/btrfs/transaction.c Hunk #2 succeeded at 1153 (offset -8 lines). patching file fs/btrfs/tree-log.c patching file fs/btrfs/volumes.c Hunk #2 succeeded at 599 (offset -2 lines). Hunk #3 succeeded at 703 (offset -2 lines). Hunk #4 succeeded at 729 (offset -2 lines). Hunk #5 succeeded at 898 (offset -2 lines). Hunk #6 succeeded at 908 (offset -2 lines). Hunk #7 succeeded at 1210 (offset -2 lines). Hunk #8 succeeded at 1307 (offset -2 lines). Hunk #9 succeeded at 1606 with fuzz 1 (offset -2 lines). Hunk #10 succeeded at 1879 (offset -3 lines). Hunk #11 succeeded at 2032 (offset -3 lines). Hunk #12 succeeded at 2053 (offset -3 lines). Hunk #13 succeeded at 2219 (offset -3 lines). Hunk #14 succeeded at 2278 (offset -3 lines). Hunk #15 succeeded at 2355 (offset -3 lines). Hunk #16 succeeded at 2570 (offset -3 lines). Hunk #17 succeeded at 2611 (offset -3 lines). Hunk #18 succeeded at 2673 (offset -3 lines). patching file fs/btrfs/volumes.h Hunk #2 succeeded at 139 (offset -1 lines). patching file fs/btrfs/zlib.c
I to wszystko?
I ten drugi w tamtym poście zalecany [PATCH] fix (latent?) memory corruption in btrfs_encode_fh() zapisałem do pliku jako .patch i:
entoo linux # patch -p1 < '/home/marg1/[PATCH] fix (latent?) memory corruption in btrfs_encode_fh().patch' patching file fs/btrfs/export.c
Tak to ma wyglądać? :)
Czy to trzeba jeszcze rekompilować teraz? Bo nie umiem doczytać? :)
To chyba oczywiste skoro jego pliki zostały zmienione, ale ja głupi jestem :/
Ostatnio edytowany przez marg1 (2011-02-15 17:53:33)
Offline
Nakładasz cały patchset z tamtego wątku czy tylko autogroup? Coś tego Twojego posta ogarnąć nie mogę. ;)
PS Przeniosłem w odpowiedniejsze miejsce.
Offline
no ten ostatni update 7 tylko czy całe muszę?
no i już zrekompilowałem
Offline
patch -p1 < /home/marg1/2.6.37_plus_v15_coordinate-flush_inode-integrity_TOI.7z patch unexpectedly ends in middle of line patch: **** Only garbage was found in the patch input.
Offline
Rozpakuj najpierw. :)
Offline
Nie zwróciłem uwagi, że to spakowane dobra to rekompiluje :)
Może i trochę żywszy się zrobił trudno powiedzieć. ale jedyne co mogę zaobserwować, że przy spokojnym użytkowaniu miałem ok 23 % obciążenia, nie wiem czy to czymś innym było spowodowane być może, ale teraz mam do 5%
Być może sobie to wmawiam - niech ktoś podsunie pomysł, jak to przetestować ;)
Flash na pełnym ekranie jak by lepiej chodzi, bo zawsze trochę nie nadążał...
Ale to wszystko może być złudzenie, więc nie bierzcie tego na serio :)
Chociaż jak rozumiem, to chodzi bardziej o odporność na obciążenia, że podczas obciążenia komp więcej zniesie, jeśli dobrze rozumiem co Arn miał namyśli :)
Ostatnio edytowany przez marg1 (2011-02-15 18:52:36)
Offline
Na razie łata autogroup działa z grupowaniem dla poszczególnych tty, nie radzi sobie z terminalami.
Dlatego jak odpalam w terminalu jakąś kompilację, to przymula kompa, jak na konsoli tekstowej (tty1 - 6), nie widać żadnego zwolnienia kompa.
Gotowa wersja ma być w 2.6.38 (stabilnym) - czyli za około 1 - 2 miesiące.
Także na pełne grupowanie procesów trzeba jeszcze poczekać.
Ostatnio edytowany przez Jacekalex (2011-02-15 19:02:44)
Offline
Jacekalex napisał(-a):
Na razie łata autogroup działa z grupowaniem dla poszczególnych tty, nie radzi sobie z terminalami.
Chyba nie jesteś na bieżąco. ;)
│ CONFIG_SCHED_AUTOGROUP:
│
│ This option optimizes the scheduler for common desktop workloads by
│ automatically creating and populating task groups. This separation
│ of workloads isolates aggressive CPU burners (like build jobs) from
│ desktop applications. Task group autogeneration is currently based
│ upon task session.
W ogóle akurat w tym patchsecie autogoroup jest backportowane z 2.6.38 o ile dobrze pamiętam.
Offline
Niedawno czytałem, że właśnie próbują poprawić ten błąd, ale w 2.6.38-rc3 jeszcze to nie działało, jak powinno.
Poza tym backportowane z rc3 czy rc4, czy może rc4-git8?
W pełni stabilne rozwiązanie ma być w stabilnym 2.6.38.
Offline
Nie wiem z jakiego, ale per tty został dawno porzucony... per session jest już chyba od listopada.
https://lkml.org/lkml/2010/11/30/121
Offline
A ja sobie nałożyłem, najnowszego patcha z kernel.oeg 2.6.38-rc8
I patrzcie co mi się zrobiło :)
Coś się pluje o ten autodrop, co wcześniej nałożyłem :)
make && make modules_install && make install CHK include/linux/version.h CHK include/generated/utsrelease.h CC arch/x86/kernel/asm-offsets.s In file included from include/linux/crypto.h:21:0, from arch/x86/kernel/asm-offsets_64.c:8, from arch/x86/kernel/asm-offsets.c:4: include/linux/module.h:342:15: error: duplicate member ‘init_ro_size’ include/linux/module.h:342:29: error: duplicate member ‘core_ro_size’ In file included from arch/x86/kernel/asm-offsets_64.c:9:0, from arch/x86/kernel/asm-offsets.c:4: include/linux/sched.h:1988:20: error: redefinition of ‘sched_autogroup_create_attach’ include/linux/sched.h:1970:20: note: previous definition of ‘sched_autogroup_create_attach’ was here include/linux/sched.h:1989:20: error: redefinition of ‘sched_autogroup_detach’ include/linux/sched.h:1971:20: note: previous definition of ‘sched_autogroup_detach’ was here include/linux/sched.h:1990:20: error: redefinition of ‘sched_autogroup_fork’ include/linux/sched.h:1972:20: note: previous definition of ‘sched_autogroup_fork’ was here include/linux/sched.h:1991:20: error: redefinition of ‘sched_autogroup_exit’ include/linux/sched.h:1973:20: note: previous definition of ‘sched_autogroup_exit’ was here make[1]: *** [arch/x86/kernel/asm-offsets.s] Błąd 1 make: *** [prepare0] Błąd 2
I co teraz? :D
Offline
Co to jest "autodrop"? ;) Patcha 2.6.38-rc8 nakłada się na czyste 2.6.37, po jego nałożeniu nie jest to już 2.6.37, tylko 2.6.38-rc8 właśnie. Jak ma się to do patchsetu o którym wcześniej pisaliśmy? Nijak... Nie będzie pasował, na 100% miałeś rejecty.
BTW, łata autogroup której ten wątek dotyczy od jądra 2.6.38 jest już w mainline.
Offline