Z tego co wiem obecnie nie powinno być problemów.
Pozdrawiam
-- 23 gru 2013 09:20 --
Przy okazji Ktoś zapytał mnie jak to się dzieje, że wydajność moich kerneli w zakresie szybkości operacji dyskowych jest nawet 30 % wyższa niż generic`a, a operacji wyjścia/wejścia [I/O] nawet o 40 % lepsza od generica. Podczas gdy pozostałe testy na podobnym poziomie albo w skrajnych przypadkach minimalnie niżej. Zatem tak, jak pisałem dla mnie priorytetem jest wygoda korzystania z sytemu [responsywność], przy zachowaniu maksymalnej wydajności i energooszczędności. Oczywiście mogę skonstruować kernele, które będą nawet 20 - 30 % wydajniejsze od generyków w testach syntetycznych ... jednak ucierpiałyby na tym, zarówno responsywność, jak i energooszczędność. Przykładowo kernel generic wyłącza pewne opcje oszczędzania energii ... bo skutkują one utrata wydajności ... w związku z tym temperatury na genericach nie zejdą tak nisko w trybach mniejszego obciążenia oraz idle , jak pod moimi. Oczywiście, aby włączyć te opcje i nie stracić na wydajności i responsywności trzeba się sporo "nagimnastykować", ale się da
. Dam tu proste porównanie ... moje kernele są tak zbudowane, że schedulery [planiści zadań dla procesora oraz I/O] kernela na pierwszym miejscu stawiają użytkownika i odpowiedzi na jego zapytania ... w przypadku kerneli generic użytkownik "stoi" co najwyżej na środku tej skali, a czasem i "niżej" ... a aby zbudować maksymalnie wydajny kernel bez oglądania się na responsywność i energooszczędność, trzeba użytkownika umiejscowić na "samym kocu". Kiedyś zbudowałem taki kernel i pokazałem Koledze, który lubuje się we wszelkich benchmarkach [pod Windows] i zapuściłem testy syntetyczne pod genericiem, a następnie moim [tym maksymalnie wydajnym buildem] ... był zachwycony dość dużym skokiem wydajności [nawet 27 %] ... następnie poprosiłem go o porównanie tego kernela z kernelem v26.x [już nie pamiętam numerku], pracował na każdym po ok 30 minut i konkluzja była taka ... stwierdził, że na tym najbardziej wydajnym kernelu nie da się pracować, co chwile system "frezuje" i wolno reaguje na polecenia, podczas gdy v26.x działa "genialnie szybko" ... i właśnie to jest clue, albo budujemy pod benchmarki, albo dla przyjemności "obcowania" z systemem
. Ja dążę zawsze do zachowania tzw. "złotych proporcji" = maksymalizacji każdego aspektu, przy minimalizacji "kosztów" związanych z wdrażaniem każdego z nich: responsywność <> wydajność <> energooszczędność <> bezpieczeństwo
.
Przy okazji już testuje v27.4, które to kernele są do 10 % wydajniejsze od v27.3 ... i udało mi się to osiągnąć bez pogorszenia responsywności i energooszczędności kerneli ... jeśli nie natrafię na jakieś problemy, tak będą zbudowane udostępnione wersje v27.3
Pozdrawiam
Bo wypatruje tej twojej "pierwszej gwiazdki" 
ale dziala OK
