LINUX.ORG.RU

Для ядра Linux написан патч, многократно улучшающий отзывчивость системы

 


0

5

Майк Галбрейт (Mike Galbraith) написал патч, многократно улучшающий отзывчивость системы при использовании многопоточных фоновых приложений, таких как, например, компиляции. Линус Торвальдс проверил и высоко оценил данную работу. К примеру, он запустил сборку — 'make -j64' — и при этом система оставалась отзывчивой, а прокрутка в веб-браузере — плавной. Торвальдс прокомментировал патч так: «that's a killer feature».

>>> Подробности

★★★★★

Проверено: svu ()
Последнее исправление: Dendy (всего исправлений: 1)
Ответ на: комментарий от Balthazar

На скорости упаковки p7zip и paq. Они гарантированно упрутся в память и проц, если конечно вы не на дискету пишете.

devl547 ★★★★★
()
Ответ на: комментарий от Hokum

Так она ни у кого практически не используется на десктопе, не показательно.
Однако у тех, у кого используется - бага нет.

RussianNeuroMancer ★★★★★
()
Ответ на: комментарий от Boboms

>Поработав 4 дня на ХР при большой нагрузке на HDD, с удивлением заметил, что отзывчивость системы стемится к нулю.

В XP одинаково высокий приоритет
Обновись. В 6.1 планировщик значительно улучшен

wxw ★★★★★
()
Ответ на: комментарий от wxw

Мне вот интересно, каким образом ты это узнал? Сырцов нет, тех.новости по изменению в коде МС не публикует...
Значит Пиар менеджер напел что отзывчивость улучшилась сказочно, а ты теперь нажимешь на кнопочки и вот, буквально чувствуешь, да! да! На самом деле непревзодённо быстрее переключается!
Ну а то что сами потоки начали обрабатываться и выполняться медленнее это мы конечно пропустили мимо ушей, про это нам ПИАР манагер забыл сказать.

anonymous
()
Ответ на: комментарий от froggy

>На скорости упаковки paq8 они упрутся в память и проц, даже если вы на дискету пишете.

Если на дискету - в память не «упрутся»

Led ★★★☆☆
()
Ответ на: комментарий от Boboms

>12309 и похожее в ХР - это не баг ОС, а архитектурные (аппаратные) «особенности» PC-совм. железа.

Которых нет на маках? Нет, это таки проблема операционки. Хотя мак работает как с этой вашей революционной компиляцией, копирование файлов немного медленнее, зато другой софт не тормозит.

На самом деле тут тоже подвисает, если анпример изменить «на живую» размер системного раздела, будет мертвый стоп на пару секунд, но искусственный ли он (может защита) или вызван подобной проблемой - фиг его знает, лень изучать.

falsificatio
()
Ответ на: комментарий от falsificatio

Которых нет на маках? Нет, это таки проблема операционки. Хотя мак работает как с этой вашей революционной компиляцией, копирование файлов немного медленнее, зато другой софт не тормозит.

Попробуйте вставить заведомо битый DVD (искарёженный) и в процессе его инициализации походить по папкам. Интересно, какое будет торможение и будет ли?

Boboms ★★
()
Ответ на: комментарий от Boboms

>Попробуйте вставить заведомо битый DVD (искарёженный) и в процессе его инициализации походить по папкам. Интересно, какое будет торможение и будет ли?

Нет, не тормозит.

falsificatio
()
Ответ на: комментарий от Led

это известно, но как объем дискеты влияет на потребление памяти?

froggy
()
Ответ на: комментарий от devl547

Речь идео о распаковке, как было отмечено в оригинальном посте.

А насчет процессора... Не думаю, что на моем воркстейшене скорость процессора будет узким местом при распаковке:

скрин

Balthazar
()
Ответ на: комментарий от Balthazar

Дело в том что симметричный алгоритм вам бы больше подошел,
посудите сами бекап вы делаете пусть раз в неделю,
восстанавливаете из бекапа еще реже,
так зачем вам распаковка в шесть раз быстрее,
уж лучше наоборот быстро упаковать, и не мучится (постоянно),
а потом немного подождать при восстановлении (редко)

froggy
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.