|
|
3.50, _KUL (ok), 12:44, 31/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
Во во! Еще и со сжатием, которое нагрузит маленький цпу за зря. Резонный вопрос - если это из-за большой ОЗУ, то тогда зачем вообще делать своп в озу???
| |
|
4.57, ананим (?), 13:40, 31/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
Вот этот для вас достаточно маленький?
$ cat /proc/cpuinfo
Processor : ARMv7 Processor rev 0 (v7l)
processor : 0
BogoMIPS : 38.40
processor : 1
BogoMIPS : 38.40
processor : 2
BogoMIPS : 38.40
processor : 3
BogoMIPS : 38.40
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
CPU implementer : 0x51
CPU architecture: 7
CPU variant : 0x2
CPU part : 0x06f
CPU revision : 0
Hardware : Qualcomm MSM 8974 (Flattened Device Tree)
Revision : 0000
Serial : 0000000000000000
| |
4.67, ram_scan (?), 14:25, 31/03/2014 [^] [^^] [^^^] [ответить]
| +13 +/– |
Узким местом давно стала не числомолотилка а шина и память что на ней болтается. Поэтому при кажущейся абсурдности такого изврата профит таки получается. Распаковать блок памяти выходит быстрее чем прогнать его по шине непакованным.
| |
|
5.73, pavlinux (ok), 16:08, 31/03/2014 [^] [^^] [^^^] [ответить]
| –8 +/– |
Мозг у тя узкое место.
Посчитай на досуге, сколько тактов проца нужно, чтоб переколбасить
в течении минуты, поток, со скоростью 6 Гб/сек. (прим. скорость шины).
Для справки PCI Express 3.0 прим. 26 Гб/сек., HyperTransport 3.0 около 40 Гб/сек.
Собственно, благодаря таким адцким скоростям, стало выгоднее делать блейд-сервера
и кластеры, а не 1024 процессорные материнки.
| |
|
6.80, noname 002 (?), 17:17, 31/03/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
Вы вот, гражданин, сначала попробуйте, потом говорите, я ощущаю профит и еще какой...
| |
|
7.85, www2 (??), 18:46, 31/03/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
Ощущаете, но не понимаете, откуда он взялся. Ваше объяснение негодное. Шина тут не при чём, тут при чём скорость чтения-записи и позиционирования головок на жёстких дисках. С SSD такой проблемы нет - там уже всё упирается в скорость SATA. Придумают более быстрый интерфейс - профит от сжатого свопа в оперативке будет ещё меньше.
| |
7.109, pavlinux (ok), 01:17, 01/04/2014 [^] [^^] [^^^] [ответить]
| –4 +/– |
> Вы вот, гражданин, сначала попробуйте, потом говорите, я ощущаю профит и еще
> какой...
Иди в венду ощущай. Млять, откуда вас столько выросло. Ощущают профит они... уссаца.
| |
|
6.122, Аноним (-), 12:02, 01/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Для справки PCI Express 3.0 прим. 26 Гб/сек., HyperTransport 3.0 около 40 Гб/сек.
Ты уверен что на его девайсе с ARMv7 они есть? :)
> Собственно, благодаря таким адцким скоростям, стало выгоднее делать блейд-сервера
> и кластеры, а не 1024 процессорные материнки.
А диски как были слоупочными, так и остались. Поэтому своп на них - отвратителен по скорости работы. Свопиться на SSD - протрется в момент. Ну вот и пришли к компромиссному варианту - свопиться в оперативку :).
| |
6.140, Аноним (-), 15:53, 01/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
Можно подробнее?
Интересно знать, каким местом ацкие скорости PCIe и HT имеют отношение к построению кластеров.
| |
|
|
4.93, Аноним (-), 19:55, 31/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Во во! Еще и со сжатием, которое нагрузит маленький цпу за зря.
Весьма зависит от того как это соотновится с I/O. Если I/O медленный, почему бы нет? :)
| |
|
|
2.16, Аноним (-), 10:06, 31/03/2014 [^] [^^] [^^^] [ответить]
| –2 +/– |
1). Берём легко сжимаемые данные.
2). Помещаем их в ZRAM, забив всё доступное место. Например 8 Гб при физически доступных 2 Гб.
3). Внезапно удаляем 8 Гб легко сжимаемых данных и забиваем тяжело сжимаемыми данными, например H264-видео.
4). ????
5). Kernel Panic.
Ну серьёзно, зачем умещать 700 Мб в 500 Мб, если внезапно может заполниться память? Зачем вообще хранить SWAP в памяти?! И это уже традиция в Linux. То фирменную технологию Google примут в ядро, которая позволяет на гигабайтной флешке создать сто стогигабайтных файлов, потому что "У нас на GMail лишь 1% использует все свои 100 Гб почты, так нафига месту простаивать?". То отложенную запись внедрят, чтобы добиться мифической скорости записи на диск, тогда как физически записи не было.
| |
|
3.30, Zenitur (ok), 11:30, 31/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
Помнишь шутку про китайцев, которые попробовали по 1 пароль? Если каждый китаец зарегистрируется в GMail и заполнит на 100% своё место, GMail "упадёт"!
| |
|
4.56, anonymous (??), 13:21, 31/03/2014 [^] [^^] [^^^] [ответить]
| –3 +/– |
>Затем, что диск - узкое место большинства систем. Ваш кэп.
Но зачем? Если памяти и так хватает, то нафиг подкачку. Прям веднузятничество какой-то. Только венда умудряется использовать своп при на 80% свободной памяти.
| |
|
5.60, rshadow (ok), 14:01, 31/03/2014 [^] [^^] [^^^] [ответить]
| +5 +/– |
Если памяти хватает, то и zram и swap остаются пустыми. Снова, ваш кэп.
| |
5.123, Аноним (-), 12:05, 01/04/2014 [^] [^^] [^^^] [ответить]
| +3 +/– |
> Но зачем? Если памяти и так хватает, то нафиг подкачку.
Довольно странно использовать zRAM, если памяти хватает. А вот когда ее МАЛО, при современной мощности числокрушилок сжатие может быть шустрее чем запись на тормозной носитель. Особенно на всяких мелких девайсах типа мобилок и т.п..
| |
|
|
3.62, Константин (??), 14:14, 31/03/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
Панику легко исключить резервированием достаточного дискового пространства для помещения несжатых данных. А все остальное - для скорости, как уже было сказано. Сейчас уже просто работающая система мало кого устроит, кроме энтузиаста. В ЦОДах подавай эффективность, хоть винду ставь...
| |
|
4.141, Аноним (-), 15:56, 01/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
> сказано. Сейчас уже просто работающая система мало кого устроит, кроме энтузиаста.
> В ЦОДах подавай эффективность, хоть винду ставь...
Странно. Я как-то всё больше слова про надёжность слыхал, если в контексте ЦОДов...
| |
|
5.144, Константин (??), 16:30, 01/04/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> сказано. Сейчас уже просто работающая система мало кого устроит, кроме энтузиаста.
>> В ЦОДах подавай эффективность, хоть винду ставь...
> Странно. Я как-то всё больше слова про надёжность слыхал, если в контексте
> ЦОДов...
Надежность (оно же "чтоб работало") - необходимое условие. Но не достаточное. Хотя конечно оно одно из первых обсуждается. ИМХО конечно.
| |
|
|
3.87, www2 (??), 19:06, 31/03/2014 [^] [^^] [^^^] [ответить] | +4 +/– | И при чём тут сжимаемость данных Все 8 гигабайт этого видео не потребуются одно... большой текст свёрнут, показать | |
|
4.142, Аноним (-), 16:00, 01/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
>>То отложенную запись внедрят, чтобы добиться мифической скорости записи на диск, тогда как физически записи не было.
> Не мифической, а очень даже реальной. СУБД может сотни раз в секунду
> перезаписывать одни и те же данные. Сделать сотни записей на диск
> или одну - есть разница?
Если СУБД сто раз за секунду перезаписала данные, они должны быть сто раз за секунду перезаписаны на диске. Логика BEGIN/COMMIT такое диктует для RDBMS, вроде как. Вернулись из COMMIT — данные ГАРАНТИРОВАННО записаны на диск.
Если RDBMS заставляют сто раз в секунду перезаписывать одно и то же, кэшированием записи на диск это не решить, и не нужно.
| |
|
3.95, Андрей (??), 20:59, 31/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
Вы не правы. Сжатие подкачки - это именно оно и есть. До того, как данные попадут в своп, они будут сжаты, что уменьшает количество дисковых оперций. Если памяти всё же не будет хватать - эти сжатые двнные будут вытеснены в своп. Не совсем понятно, зачем забивать память тяжкло сжимаемыми данными.
| |
3.121, Anonym2 (?), 10:51, 01/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
> То отложенную запись внедрят, чтобы добиться мифической
> скорости записи на диск, тогда как физически записи не было.
Ну скажем SSD имеют иногда довольно ограниченные ресурсы по части перезаписи...
| |
|
2.17, Аноним (-), 10:06, 31/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
zram - это очень хорошо. Я его даже бэкпортировал на свое ядро 2.6.24.7 для IP приставки(blob'ы мешают перейти на что-то свежее)
| |
|
3.41, Seyko (?), 11:52, 31/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
А сложно портировать? Меня интересует перенос в openvz-el6... Полезная фича для
встроенных устройств с их погибающим от частой записи flash-ПЗУ
| |
|
4.51, AlexAT (ok), 12:46, 31/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
> А сложно портировать? Меня интересует перенос в openvz-el6... Полезная фича для
> встроенных устройств с их погибающим от частой записи flash-ПЗУ
Сейчас делаю вариант патча для ядра el6, если всё пройдёт нормально - выложу на тест.
В ядре el6 zram из staging, к слову, уже имеется, однако он слишком старый.
К сожалению, просто модулем - не получится, zram требует наличия аллокатора zsmalloc в mm-подсистеме ядра, в ядре el6 его нет. Поэтому только полная пересборка.
| |
4.75, Аноним (-), 16:11, 31/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
Портировать не сложно. Также модифицировать: так как в системе имелись статические буфера для видео/аудио декодеров и т.п., которые не использовались в некоторых случаях(загрузка обновлений в RAM и запись их во flash после загрузки), то был написан дополнительный allocator для модуля zram, который помещал несжимаемые данные в эти буфера.
| |
4.90, AlexAT (ok), 19:30, 31/03/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
> А сложно портировать? Меня интересует перенос в openvz-el6... Полезная фича для
> встроенных устройств с их погибающим от частой записи flash-ПЗУ
Вариант для CentOS 6 тут:
http://alex-at.ru/linux/zram-c6
Для ядра OpenVZ адаптировать составить труда не должно - патч тот же, только .spec и конфиг чуток подправить.
| |
|
|
2.23, WherWolf (?), 11:05, 31/03/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
Интересно, можно ли будет хранить в сжатом виде не раздел подкачки, а, например, /var/log?
| |
|
3.25, ананим (?), 11:18, 31/03/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
Вы хотите логи в ram держать?
Плохая идея.
К тому же для логов итак логротэйт есть. С сжатием архивов и тд.
| |
|
4.48, Аноним (-), 12:39, 31/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Вы хотите логи в ram держать?
> Плохая идея.
> К тому же для логов итак логротэйт есть. С сжатием архивов и
> тд.
Некоторые виды устройств, хранят логи в RAM памяти. Обычно на таких устройствах RAM в 4 раза больше чем Flash
| |
|
5.58, ананим (?), 13:51, 31/03/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
И что это должно доказывать?
Что syslog должен теперь (как и эти устройства) в озу всё держать?
Зыж
эти устройства рассчитывают что их логи кто-то забирает.
а если не забирает, то значит и не нужны, что в общем случае тут и не рассматривается (не ведите их тогда вообще).
| |
|
|
3.35, Lain_13 (ok), 11:36, 31/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
Если ты боишься испортить логами новый SSD диск, то совершенно зря. Тебе придётся писать логи на полной скорости винта несколько лет к ряду, чтоб его испортить. А переносить логи в память просто так это действительно плохая идея.
| |
|
4.124, Аноним (-), 12:12, 01/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
> на полной скорости винта несколько лет к ряду, чтоб его испортить.
Ага, ЩАЗ. Типичный NAND выдерживает 1-2 тысячи записей. За год можно переписать содержимое винта явно более 1000 раз. Другое дело что мало у кого такой конский объем логов.
| |
|
5.138, Lain_13_too_lazy_to_login (?), 13:44, 01/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
Сейчас все типичные SSD делают на TLC и MLC, а это 5 и 10 тысяч циклов. Нетипичные делают на SLC и это 100 000 и дорого. Ок, согласен, что про полную скорость я загнул, но логи в таких конских объёмах действительно редко пишутся и SSD на 120 Гб прослужит достаточно долго. В конце-концов тебе понадобится записать туда петабайт данных, чтоб высадить все ячейки. На современных винтах обычно указывают время до первого отказа при нормальной нагрузке и это обычно 1 200 000 часов для 120 Гб MLC (более 100 лет). Т.е. это если ты не пытаешься использовать винт на файловом сервере, например, с постоянной записью.
| |
|
|
|
|
1.4, Аноним (-), 09:03, 31/03/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –8 +/– |
Пугаясь размеру ядра от релиза к релизу, хочу спросить - сколько они занимают места?
| |
|
2.12, VldK (ok), 09:55, 31/03/2014 [^] [^^] [^^^] [ответить]
| +4 +/– |
В 4мб флеша моего роутера влезает помимо ядра 3.10 еще и вебморда с бизибоксом.
| |
2.28, Аноним (-), 11:25, 31/03/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
Не пугайся. В винде драйвера отдельно от ядра, а здесь вместе. Поэтому сбивает с толку. Все драйвера лежат отдельно от ядра - в виде модулей (если не монолит).
| |
2.113, Андрей (??), 08:31, 01/04/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
-rw-r--r-- 1 root root 6533680 апр 1 07:07 kernel-3.14.0-gentoo
lz4
ну да, на дискету уже давно не влазят...
| |
|
|
2.79, Пиу (ok), 17:12, 31/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
а они (или кто-нибудь) дрова в меинстрим спортировали? Грег говорил, что это удивительно, что rpi-шное ведро вообще работает
| |
|
1.13, Fracta1L (ok), 10:00, 31/03/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
> Для файловой системы Btrfs расширен объём информации, предоставляемой через sysfs, в том числе теперь можно получить данные о доступных возможностях и использовании дискового пространства
Отлично. А то с аудитом у Btrfs плоховато.
| |
|
|
3.22, ананим (?), 10:59, 31/03/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
А.. да-да.
Не буду вам мешать общаться на "профессиональную" тему.
Зыж
Ха! Павлины говоришь?
| |
3.132, Аноним (-), 12:36, 01/04/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
> c btrfs вообще всё плоховато
Да, только вон фэйсбучек собирается тестовый деплоймент делать, зюзя на нее переходит. Но у нас то тут мегаадмины суперэнтерпрайзов, у местных экспертов у каждого по три инсталляции размером с два фэйсбука каждая, и уж конечно они свой дистр выпускают, даже два.
| |
|
2.21, ананим (?), 10:55, 31/03/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
Аудит вешается на vfs.
А то что вы подумали, называется отладка, профайлинг,.. всё что угодно, но точно не аудит.
(Кстати то, про что вы подумали включается при конфигурации ядра/модуля ядра)
| |
|
1.27, Аноним (-), 11:24, 31/03/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Объясните, зачем нужен zram? Всё исключительно из-за сжатия и теоретической возможности уместить больше данных в рам?
| |
|
2.32, ананим (?), 11:30, 31/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
Да. Посмотрите кто именно этим заинтересован.
В телефонах/планшетах иметь свап на ссд не всем нравится. Это уменьшает ресурс девайса (особенно когда в него хотят запихнуть железки из разряда "по-дешевле")
| |
|
3.152, Аноним (-), 13:15, 02/04/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
Но зачем нужно свапаться в оперативную память, если есть свободная оперативная память?
| |
|
4.153, AlexAT (ok), 13:21, 02/04/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Но зачем нужно свапаться в оперативную память, если есть свободная оперативная память?
Сжатие, сэр. Это несколько шустрее, чем посвопаться на диск. Тратя память на своп в ZRAM, в итоге получаем свободную память за счёт сжатия того, что "высвопили".
| |
|
|
2.125, Аноним (-), 12:16, 01/04/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
> теоретической возможности уместить больше данных в рам?
Поскольку большинство содержимого RAM отлично жмется, а упаковка/распаковка RAM быстрее чем запись на тормозной диск - можно в ряде ситуаций поиметь профит.
| |
|
1.38, Аноним (-), 11:44, 31/03/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>В DRM-модуле драйвера Nouveau добавлена поддержка GPU NVIDIA серии GK110 ( GeForce GTX 780, GTX Titan) и GK208 (GeForce 630/640).
Надо же, и года не прошло. Попробовать, чтoле?
| |
|
|
3.88, Аноним (-), 19:10, 31/03/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
Не, целый год страдал на проприетарном драйвере. Плакал по ночам в подушку. Донатил мозелеедам во искупление греха сего.
| |
|
|
1.39, Аноним (-), 11:47, 31/03/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
А что будет с hibernate, если своп в раме? Я надеюсь, его не повключают везде по дефолту?
| |
|
2.46, Andrew Kolchoogin (ok), 12:23, 31/03/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
В привычном смысле Hibernate в мобильных устройствах отсутствует, связь с ОпСоС'ом хотелось бы поддерживать постоянно. :)
| |
|
3.52, Аноним (-), 12:52, 31/03/2014 [^] [^^] [^^^] [ответить]
| –4 +/– |
Я про десктоп, вообще-то. Ведро-то одно на всех. Впрочем, путать декстоп с "мабилой", видимо, уже традиция среди линуховых погромистов.
| |
|
4.68, llolik (ok), 14:29, 31/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
>путать декстоп с "мабилой", видимо, уже традиция среди линуховых погромистов
как и забывать, что не везде используют ванильное ядро, среди "кулхацкеров".
| |
4.115, Андрей (??), 08:36, 01/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Я про десктоп, вообще-то. Ведро-то одно на всех. Впрочем, путать декстоп с
> "мабилой", видимо, уже традиция среди линуховых погромистов.
Нормально всё - в сжатом виде и пишется. При загрузке разжимается...
| |
|
|
2.54, Imprtat (?), 13:01, 31/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
Данные "лежат" в zram до появления необходимости записать из на диск.
Использовал zram в паре с убитым диском, очень выручал.
| |
|
|
2.69, Аноним (69), 14:35, 31/03/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
с разморозкой!!
# egrep "(ZSWAP|ZRAM)" /usr/src/.config
CONFIG_ZSWAP=y
CONFIG_ZRAM=y
# CONFIG_ZRAM_DEBUG is not set
| |
|
1.44, ua9oas (ok), 12:13, 31/03/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
В состав каких дистрибутивов оно войдет? Каков будет срок его жизни? Насколько больше устройств в нем поддерживается по сравнению с другими ветками ядра?
| |
|
2.116, Андрей (??), 08:38, 01/04/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
> В состав каких дистрибутивов оно войдет? Каков будет срок его жизни?
> Насколько больше устройств в нем поддерживается по сравнению с другими ветками
> ядра?
не знаю как в других дистрах, но в gentoo-patches уже полгода точно присутствует...
| |
|
3.126, Аноним (-), 12:19, 01/04/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
> полгода точно присутствует...
Мюнхаузен, залогинься! Ядро 3.14 пилят менее 2 месяцев, IIRC.
| |
|
|
1.59, svsd_val (ok), 13:54, 31/03/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Кстати народ может кто нибудь ответить как избавится от сильных подвисаний если озу кончалось???
OOM уж больно долго думает (около 5-10минут) перед тем как убить тот или иной процесс, при этом пробовал ставить vm.oom_kill_allocating_task = 1 не помогло =(
| |
|
2.63, Аноним (-), 14:14, 31/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
Сделать swap меньше. Пока kswapd будет способен перекидывать страницы между ram и swap, у OOM не будет причин сработать.
| |
|
3.84, svsd_val (ok), 17:46, 31/03/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
У меня просто 16gb, я свап вообще не врубал, думал что он влияет на OOM killer....
| |
|
4.127, Аноним (-), 12:20, 01/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
> У меня просто 16gb, я свап вообще не врубал,
Ну и правильно. Нафиг вам своп с 16Гб?
| |
|
5.134, svsd_val (ok), 13:23, 01/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
Дык, вот поэтому его и не врубал, но каким то макаром, смог повесить систему на минут 5-10 при срабатывании OOM Killer'а Oo
| |
|
6.151, Linux 3.14 (?), 12:37, 02/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Дык, вот поэтому его и не врубал, но каким то макаром, смог
> повесить систему на минут 5-10 при срабатывании OOM Killer'а Oo
Просто ядро при недостатке памяти сначала сбрасывает все дисковые кэши и потом при каждом обращении к файловой системе ходит непосредственно на диск, а не в кэш. И это выглядит как подвисание, несмотря на то, что свопа в системе нет вовсе.
| |
|
|
|
|
2.117, Андрей (??), 08:39, 01/04/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Кстати народ может кто нибудь ответить как избавится от сильных подвисаний если
> озу кончалось???
> OOM уж больно долго думает (около 5-10минут) перед тем как убить тот
> или иной процесс, при этом пробовал ставить vm.oom_kill_allocating_task = 1 не
> помогло =(
А в BSD наоборот - очень быстро :D
| |
|
3.136, svsd_val (ok), 13:27, 01/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
>> Кстати народ может кто нибудь ответить как избавится от сильных подвисаний если
>> озу кончалось???
>> OOM уж больно долго думает (около 5-10минут) перед тем как убить тот
>> или иной процесс, при этом пробовал ставить vm.oom_kill_allocating_task = 1 не
>> помогло =(
> А в BSD наоборот - очень быстро :D
Угу при "ручном" аллокэйте - он срабатывает мгновенно, но скорее всего из-за видюхи (она юзает часть озу) он и повесился на это время. (Видюха встроенная Intel GMA)
| |
|
2.130, Аноним (-), 12:31, 01/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
> OOM уж больно долго думает (около 5-10минут) перед тем как убить тот
> или иной процесс,
Что за нафиг? У меня пристреливается за считанные секунды. Сабжевый кернел как раз, 16 гиг памяти. Случайно ухитрился таки выюзать - файрфокс и выюзавшая программа пристрелились весьма резво.
| |
|
3.137, svsd_val (ok), 13:30, 01/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
>> OOM уж больно долго думает (около 5-10минут) перед тем как убить тот
>> или иной процесс,
> Что за нафиг? У меня пристреливается за считанные секунды. Сабжевый кернел как
> раз, 16 гиг памяти. Случайно ухитрился таки выюзать - файрфокс и
> выюзавшая программа пристрелились весьма резво.
Похоже это из-за того что у меня в то время была запущена игрушка и она начала аллокейтить озу в видюхе, в то время когда кончалась озу и вот результат .. (видюха встроенная intel gma)
| |
|
2.146, Аноним (-), 20:37, 01/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
Что значит "сильные подвисания"? Зависание оно или есть, или его нет. Просто как немного беременная.
| |
|
|
2.118, Андрей (??), 08:41, 01/04/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Это ж блин Пи ядро :)
точно же! щас в грубе версию поправлю :)
| |
|
|
2.107, pavlinux (ok), 01:07, 01/04/2014 [^] [^^] [^^^] [ответить]
| –5 +/– |
> Бэкпорт для CentOS 6 тут:
А нах..й бэкпорт-то? :) Оно с ядра 2.6.33 валяется никому не нужное.,
а еще раньше валялось ненужное под именем compcache на гуглекоде.
Какие-то вы тормоза. :D
| |
|
3.112, AlexAT (ok), 08:14, 01/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
> А нах..й бэкпорт-то? :) Оно с ядра 2.6.33 валяется никому не нужное.,
На самом деле для специфичных применений вполне нужное, но из staging бэкпортировать было лениво.
| |
|
4.133, Andrey Mitrofanov (?), 13:16, 01/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
>> А нах..й бэкпорт-то? :) Оно с ядра 2.6.33 валяется никому не нужное.,
> вполне нужное, но из staging бэкпортировать было лениво.
/lib/modules/2.6.32-279.el6.x86_64/kernel/drivers/staging/zram/zram.ko
?? П-поясни? Чем твой "бэкпорт" лучше /staging?
| |
|
5.135, AlexAT (ok), 13:27, 01/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
> ?? П-поясни? Чем твой "бэкпорт" лучше /staging?
Пока драйвер находился в staging - он не считался готовым к использованию. Между 3.13 и 3.14 в него, собственно, внесено некоторое число изменений. Это раз.
Если сравнивать со staging из штатного ядра RHEL - то там совсем тихий ужас. Во-первых, используется старый, как говно мамонта, вариант. Во-вторых, там используется другой, "навесной" аллокатор для сжатых страниц.
| |
|
|
3.129, Аноним (-), 12:28, 01/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
> А нах..й бэкпорт-то? :) Оно с ядра 2.6.33 валяется никому не нyжное.,
Пока ты каркал, это замайнлайнили. Прокаркал ты свой тезис.
| |
|
4.155, pavlinux (ok), 14:07, 04/04/2014 [^] [^^] [^^^] [ответить]
| –2 +/– |
Лошара ты малолетняя. Пока ты ф школе азбуку учил, я эту куету вдоль и поперёк изучил.
Хрень это не нужная. Для ИБД можешь заюзать ZSWAP
| |
|
|
|
1.102, Аноним (-), 23:33, 31/03/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
> изменений внесено сотрудниками компании Intel, 7.3%
AMD пофиг на Linux, интересно как там дела с 3DNow!
| |
|
2.106, Led (ok), 01:01, 01/04/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> изменений внесено сотрудниками компании Intel, 7.3%
> AMD пофиг на Linux, интересно как там дела с 3DNow!
Вылазь из анабиоза, двоешник. 3DNow! нет начиная с бульдозера.
| |
|
3.120, Андрей (??), 08:43, 01/04/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
>>> изменений внесено сотрудниками компании Intel, 7.3%
>> AMD пофиг на Linux, интересно как там дела с 3DNow!
> Вылазь из анабиоза, двоешник. 3DNow! нет начиная с бульдозера.
<NOTROLL>Я не совсем ронял, почему они отказались от 3dnow% ?</NOTROLL>
| |
|
4.154, Stax (ok), 00:25, 03/04/2014 [^] [^^] [^^^] [ответить] | +1 +/– | Инструкции не пользовались особой популярностью Фактически большинство из них я... большой текст свёрнут, показать | |
|
|
2.128, Аноним (-), 12:26, 01/04/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
> AMD пофиг на Linux,
В чем это выражается? Процы и чипсеты поддерживаются, GPU пилят ударными темпами. А ничего иного амд вроде и не выпускает так по крупному...
| |
|
1.131, Аноням (?), 12:34, 01/04/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
А ещё Линус Торвальдс заявил об изменении нумерации сборок: следующая - 3,141, потом - 3,1415 и далее. Релиз "Тäydellisyys" выйдет после полного завершения разработки.
| |
|