После обновления до 15.04 с 14.10 заметил странное поведение системы. Система стартует нормально, но стоит запустить Chrome (а если firefox то вообще вилы) как LA поднимается до 12 (на 8 ядерном Core i7). Процессор «отъедает» полностью. Все ядра загружены на 80-99%. Попробовал поотключать/повключать настройки в Chrome тоже не помогло.
Может кто встречался с таким багом. Работать в системе вообще не возможно.
Будет ли продолжена поддержка личного кабинета по адресу mylk.qiwi.ru или поддержка будет полностью прекращена? Как долго можно будет обращаться в личный кабинет по старой ссылке?
Не совсем понятно причем тут скорость света? Она вроде как ко всему применима не только к памяти.
Допустим у нас 32 битная архитектура, а память — явно медленнее. Лезть в память за командой потом за данными или сразу прочитать 64 бита (и команду и данные), а возможно и несколько команд,- разница очевидна и как раз зависит от числа контактов.
А собственно в чём я не прав? Если расматриваем взаимодействие CPU-MEMORY по шине с точки зрения пересылок в память. именно как процесса передачи по шине, то какой смысл говорить о кэше? Или нужно было специально указывать, что произошёл промах в кэше? По-моему это итак понятно, если лезем в саму память. :)
Я исхожу из той же точки зрения, что последовательные шины годятся не везде. В данном случае применение неоправданно.
Ждал этого коммента :). Но ввиду рассмотра работы с памятью, кэш не рассматривался осознанно.
Да между сигналами и mov eax,[ebx] — огромное расстояние. Это было приведено как пример работы с памятью.
И собственно никто не говорит, что на последовательную шину перейти нельзя. Вот, например, e Itanium'а вообще кардинально другая архитектура, там есть операции по подготовке данных. Если б была архитектура с такими возможностями типа:
memory_prefetch [adr]
…
ld r0,[adr]
То почему бы и не использовать последовательную шину.
Но опять же у нас x86 :( со всеми вытекающими.
Но это не в полной мере последовательный интерфейс, скорее параллельно-последовательный.
Если рассматривать в таком ключе, то «да» и не буду спорить. Но опять же память использует 96 контактов, а у автора 100 и он утверждает, что можно обойтись 70-80 :)
А я как-то ориентировался на 2 вывода: данные, синхронизация.
Но, пусть Вы правы и можно использовать последовательную шину.
У нас есть гипотетический процессор (32 бита) работает на частоте 1 ГГц.
Вы пишете инструкцию mov eax,[ebx]
Далее мы отбрасывание транслирование адреса и т.д.
адрес преобразуется в последовательный код и передаётся в память, где происходит перевод в адрес — ну грубо как набор управляющих сигналов для получения данных из запоминающих элементов, данные прочитаны, далее память преобразует в последовательный код и отправляет процессору. Совсем забыл упомянуть о том, что есть ещё управляющие сигналы типа открыть строку, закрыть строку, выбрать банки и т.д. Мы это всё отбрасываем и будем считать, что у нас всего 64 бита. 32 адрес + 32 данные…
Если проц работает на 1 ГГц, то (справедливо для x86, от архитектуры многое зависит), этот интерфейс должен работать на 2 частоте… то есть 2*64*1ГГц… многовато не находите?
Не знаю как насчёт GDDR5.
Но выкладки в общем-то такие. 32 бита на адрес + 64 бита на данные = 96 бит уже. Иначе память будет существенно отставать от проца по скорости.
Интеграция ведёт к увеличению выводов. Модульность и разделение на чипы — к уменьшению.
Жёсткий диск — не процессор. Там где у HD возможна передача последовательным кодом и увеличение частоты, в процессоре это нереально, ввиду, несоизмеримой сложности логики работы.
На данном этапе развития слишком сложно определить грань между чистой интерпретацией и JIT. Тенденция не в уменьшении производительности софта (звучит как теория заговора… брбрр...), а в том, что производительность «кладётся» в угоду скорости и гибкости разработки.
Интеграция дала бы низкую стоимость, но тогда мы получаем то, от чего в своё время отказалась IBM, создавая PC, а именно мы теряем модульность. во-вторых, слишком сложно это всё интегрировать.
Логика к сожалению не в пользу автора. Хотя статья сама по себе интересна его мнением.
В частности, абзац про «мееееееедленное ПО», мотивацию к апгрейду, и более тонкие технические моменты типа 100 выводов на проце и интеграция «всего этого добра» на один чип.
Если посмотреть top, то в >50% CPU «отъедает» процесс kindle_inject (который, кстати, сказать в htop не светиться ).
Tasks: 281 total, 2 running, 279 sleeping, 0 stopped, 0 zombie
%Cpu(s): 24,5 us, 56,3 sy, 0,0 ni, 18,9 id, 0,0 wa, 0,0 hi, 0,2 si, 0,0 st
КиБ Mem: 7988644 total, 5070812 used, 2917832 free, 697772 buffers
КиБ Swap: 15811580 total, 0 used, 15811580 free. 1989260 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
6095 root -51 0 0 0 0 S 57,8 0,0 5:04.49 kidle_inject/1
6096 root -51 0 0 0 0 S 57,8 0,0 5:04.20 kidle_inject/2
6097 root -51 0 0 0 0 S 57,8 0,0 5:05.26 kidle_inject/3
6098 root -51 0 0 0 0 S 57,8 0,0 5:04.74 kidle_inject/4
6099 root -51 0 0 0 0 S 57,8 0,0 5:04.64 kidle_inject/5
6101 root -51 0 0 0 0 S 57,8 0,0 5:05.23 kidle_inject/7
6094 root -51 0 0 0 0 S 54,4 0,0 5:00.06 kidle_inject/0
6100 root -51 0 0 0 0 S 54,4 0,0 5:04.33 kidle_inject/6
Как показало гугление проблема в модуле ядра intel_powerclamp.
Отключив этот модуль сразу получил прирост в производительности и нормальный отклик системы.
Отключение модуля можно сделать так:
$ sudo rmmod intel_powerclamp
Придётся делать каждый раз после перезагрузки.
Либо добавив blacklist на intel_powerclamp:
# echo «blacklist intel_powerclamp» > /etc/modprobe.d/disable-powerclamp.conf
Ссылка на баг: bugs.launchpad.net/ubuntu/+source/linux/+bug/1389077
Может кому пригодится :)
Может кто встречался с таким багом. Работать в системе вообще не возможно.
Пруф
Допустим у нас 32 битная архитектура, а память — явно медленнее. Лезть в память за командой потом за данными или сразу прочитать 64 бита (и команду и данные), а возможно и несколько команд,- разница очевидна и как раз зависит от числа контактов.
Я исхожу из той же точки зрения, что последовательные шины годятся не везде. В данном случае применение неоправданно.
Вы про то, что ранних этапах конвеера определяется адрес или про последовательно расположенные данные?
Да между сигналами и mov eax,[ebx] — огромное расстояние. Это было приведено как пример работы с памятью.
И собственно никто не говорит, что на последовательную шину перейти нельзя. Вот, например, e Itanium'а вообще кардинально другая архитектура, там есть операции по подготовке данных. Если б была архитектура с такими возможностями типа:
memory_prefetch [adr]
…
ld r0,[adr]
То почему бы и не использовать последовательную шину.
Но опять же у нас x86 :( со всеми вытекающими.
Если рассматривать в таком ключе, то «да» и не буду спорить. Но опять же память использует 96 контактов, а у автора 100 и он утверждает, что можно обойтись 70-80 :)
А я как-то ориентировался на 2 вывода: данные, синхронизация.
...This enables an increase to the width of the memory without increasing the pin count…
Но, пусть Вы правы и можно использовать последовательную шину.
У нас есть гипотетический процессор (32 бита) работает на частоте 1 ГГц.
Вы пишете инструкцию mov eax,[ebx]
Далее мы отбрасывание транслирование адреса и т.д.
адрес преобразуется в последовательный код и передаётся в память, где происходит перевод в адрес — ну грубо как набор управляющих сигналов для получения данных из запоминающих элементов, данные прочитаны, далее память преобразует в последовательный код и отправляет процессору. Совсем забыл упомянуть о том, что есть ещё управляющие сигналы типа открыть строку, закрыть строку, выбрать банки и т.д. Мы это всё отбрасываем и будем считать, что у нас всего 64 бита. 32 адрес + 32 данные…
Если проц работает на 1 ГГц, то (справедливо для x86, от архитектуры многое зависит), этот интерфейс должен работать на 2 частоте… то есть 2*64*1ГГц… многовато не находите?
Но выкладки в общем-то такие. 32 бита на адрес + 64 бита на данные = 96 бит уже. Иначе память будет существенно отставать от проца по скорости.
Интеграция ведёт к увеличению выводов. Модульность и разделение на чипы — к уменьшению.
Хотя раз уж в абзаце "...advanced I/O...", то речь идёт скорее всего об периферии. так?
Интеграция дала бы низкую стоимость, но тогда мы получаем то, от чего в своё время отказалась IBM, создавая PC, а именно мы теряем модульность. во-вторых, слишком сложно это всё интегрировать.
В частности, абзац про «мееееееедленное ПО», мотивацию к апгрейду, и более тонкие технические моменты типа 100 выводов на проце и интеграция «всего этого добра» на один чип.