https://www.opennet.ru/openforum/vsluhforumID3/75408.html Линус Торвальдс анонсировал (https://lkml.org/lkml/2011/3/14/508) релиз Linux-ядра 2.6.38 (http://www.kernel.org/), в который вошли наработки по увеличению интерактивности выполнения десктоп-задач, значительно повышена масштабируемость VFS, в Btrfs обеспечена поддержка LZO-сжатия и создания доступных только на чтение снапшотов, интегрированы HugePage-патчи, добавлена поддержка процессоров AMD Fusion, добавлены новые драйверы и обеспечена поддержка mesh-протокола B.A.T.M.A.N.<br><br><br>В новую версию принято 10413 исправлений от 1349 разработчиков, размер патча - 49 Мб (добавлено 9295 тыс. строк кода, удалено - 9159 тыс. строк). Около 38% всех представленных в 2.6.38 изменений связаны с драйверами устройств, примерно 24% изменений имеют отношение к обновлению кода специфичного для аппаратных архитектур, 12% связано с сетевым стеком, 6% - файловыми системами и 4% c внутренними подсистемами ядра. <br><br><br><br>Наиболее интересные новшества (http://kernelnewbies.org/Linux_2_6_38) ядра 2.6.38: <br><br><br><br>...<br><br>URL: https://lkml.o https://www.opennet.ru/openforum/vsluhforumID3/75408.html#184 Sat, 19 Mar 2011 06:16:45 GMT я скопировал /usr/src/linux-headers-2.6.38/include/generated<br> в <br>/usr/src/linux-2.6.38/include/linux<br>и прошло ... <br> https://www.opennet.ru/openforum/vsluhforumID3/75408.html#183 Fri, 18 Mar 2011 20:27:29 GMT чёрт, в 11.04 меса 7.10.1, а не 11 (( хоть и ядро 38 :(<br> https://www.opennet.ru/openforum/vsluhforumID3/75408.html#182 Fri, 18 Mar 2011 14:11:38 GMT &gt; А в блокировании шины PCI на время копирования.<br><br>Я так понял что под оным багом каждый имеет в виду что-то свое, сваливая в кучу все мыслимые и немыслимые проблемы :). Если продолжать логику - там в треде вылез даже кто-то с фрей 8.2 которая тоже видите ли у него тормозит при копировани больших файлов. Получается что она тоже снабжена сабжевым багом...линукса? :)))<br><br> https://www.opennet.ru/openforum/vsluhforumID3/75408.html#181 Fri, 18 Mar 2011 14:05:37 GMT &gt; За время существования бага, я ни разу не видел тестов-сравнений <br>&gt; с МакОС/Венде/BSD/Solaris. dd и /dev/null иль NUL есть даже в ДОСе, <br>&gt; так что воспроизвести недолго. Я б проверил, Венду некуда ставить.<br><br>Ну, видимо орать "Linux, баг, ай-яй-яй!" проще :). Хотя если в других системах озадачить системный диск да еще не дай боже при своплении - жопа там наступает не менее масштабная. А что до доса - так он однозадачный по затее своей. И пока прога пишет в файло - просто так и без извращений ты вообще ничего делать не сможешь :)<br><br> https://www.opennet.ru/openforum/vsluhforumID3/75408.html#180 Fri, 18 Mar 2011 13:23:22 GMT Таки я Вас умоляю! null, zero, они все наодно лицо.<br> https://www.opennet.ru/openforum/vsluhforumID3/75408.html#179 Fri, 18 Mar 2011 13:19:11 GMT &gt; если только вы данные не из /dev/null берёте) <br><br>О, а вы уже научились из /dev/null доставать данные которые туда загнали? И у вас натурально отрос накопитель бесконечного объема в системе? Жаль что математикам не дают нобелевку. Но уж все остальные премии за возможность вернуть данные из /dev/null вам явно обеспечены :)<br> https://www.opennet.ru/openforum/vsluhforumID3/75408.html#178 Thu, 17 Mar 2011 19:45:57 GMT &gt;В линухе кстати поведение в таких ситуациях явно лучше - лиух вообще своп не юзает пока не начнет реально припирать, поэтому пока хватает RAM - в свопе пусто и задачи переключаются в момент. А если RAM не хватает - так кто виноват то, что вы выше головы прыгаете? <br><br>Не всегда. stumpwm+lenovo s10+slackware-current (3-х месячной давности, правда). emacs-client+doc-view+pdf (к примеру, ansi common lisp, или несколько статей со springerlink/SAGE). Жрет около половины оперативы из 1G имеющейся (ну, если там еще что в фоне висит. Так, обычно, не более 300 метров). Своп при этом, за несколько часов прет вверх, правда не сильно, метров до 150. При этом отваливается wicd-curses. Выход в саспенд часов на 10, а потом обратно приводит к превращению emacs-daemon в Чапая, который думает.<br><br>Видно придется переписывать doc-view. :( А времени, нема.<br> https://www.opennet.ru/openforum/vsluhforumID3/75408.html#177 Thu, 17 Mar 2011 13:37:45 GMT Ок, отписал ему :)<br> https://www.opennet.ru/openforum/vsluhforumID3/75408.html#176 Thu, 17 Mar 2011 12:44:39 GMT &gt; Хыыы )) Чувак ответил (когда я привел 2 блокировки из патча и <br>&gt; из ядра): <br>&gt; So you are suggesting to invoke blk_run_queue from within bfq_kick_queue. It seems <br>&gt; the right thing to do, thanks.<br>&gt; The only problem might be that, in this way, a further API <br>&gt; dependency is added. I will think about it when I will <br>&gt; release BFQ for 2.6.38.<br><br>Ну на самом деле, там те же яйцы, только вид сбоку.<br><br>&gt; Ну а когда я спросил, мол, будет ли нормально работать с автогруппировкой, <br>&gt; ответил следующее: <br>&gt; I did not have (and probably will not have) the time to <br>&gt; integrate the BFQ cgroups mechanism (whose code and has been actually <br>&gt; used to implement cgroups within CFQ) with the rest of the <br>&gt; system, so I guess BFQ does not profit from Autogrouping. But <br>&gt; I did not check. If you performed or want to perform <br>&gt; any test, I will be happy to hear about your results. <br><br>Скажи работает! :)<br><br>И я имел ввиду, не тандем BFQ+Autogroup, а чтоб они друг другу не мешались.<br>