June 14th, 2010

404

opera

С этим надо что-то делать. Она начинает меня реально бесить.

Варианты:

1) Откатиться на Qt'шную версию.
2) Начать пилить другой браузер.

Скажем... Дедлайн до конца месяца. Если проблема не решится, sayonara opera.
404

МУХАХАХАХАХАХАХА

Ещё один левелап в зене - оно ДИНАМИЧЕСКИ жрёт память. Практически неограниченно! Т.е. виртуальная машина сама запрашивает себе память, ей её накидывают. Не мгновенно, но в вполне разумное время, с небольшим упреждением. При этом, при малейшей возможности, свободную память отдадут назад, в гипервизор. Причём, сначала в своп выпихивают самых тупых засранцев (память занятую, но неиспользуемую), и только потом канючат у гипервизора. Как только память из свопа становится востребованной, так сразу же выделяется память от гипервизора.

Как это было сделано... страшно смотреть. Теперь из этого набора спичек, подпирающих перекладины нужно сделать железобетонный мост для фур.


.... Я в абсолютном восторге. Это нужно видеть. ... Как только разработчик приделает к биллингу графики, я их покажу. Просто искуственный интеллект по предсказанию потребления памяти, да и только. После очередного хапа на 100Мб оно делает резкий взбрык на 200-300Мб, потом успокаивается (объём свободной памяти плавно увеличивается).
404

xenballoon, take2

тьфу. Как всё в зене - оно примитивно и клёво. И я его одолел. У нас будет новый xenballoond, с бриджетами и йойо. На Си.
404

Секреты зена

static unsigned long minimum_target(void)
{
#ifndef CONFIG_XEN
#define max_pfn num_physpages
#endif
        unsigned long min_pages, curr_pages = current_target();

#define MB2PAGES(mb) ((mb) << (20 - PAGE_SHIFT))
        /* Simple continuous piecewiese linear function:
         *  max MiB -> min MiB  gradient
         *       0         0
         *      16        16
         *      32        24
         *     128        72    (1/2)
         *     512       168    (1/4)
         *    2048       360    (1/8)
         *    8192       552    (1/32)
         *   32768      1320
         *  131072      4392
         */
        if (max_pfn < MB2PAGES(128))
                min_pages = MB2PAGES(8) + (max_pfn >> 1);
        else if (max_pfn < MB2PAGES(512))
                min_pages = MB2PAGES(40) + (max_pfn >> 2);
        else if (max_pfn < MB2PAGES(2048))
                min_pages = MB2PAGES(104) + (max_pfn >> 3);
        else
                min_pages = MB2PAGES(296) + (max_pfn >> 5);
#undef MB2PAGES

        /* Don't enforce growth */
        return min(min_pages, curr_pages);
#ifndef CONFIG_XEN
#undef max_pfn
#endif
}


И всё сразу понятно. Минимальное количество страниц (т.е. после лёгкого движения рукой, килобайт) зависит от максимального количества страниц (... надо выяснить, как оно образуется при запуске PVM'а - как static-max, вероятнее всего...) по простенькой формуле на 8 строк. Интересно, насколько сложно будет пропатчить ядро? Я бы всё-таки хотел иметь balloon'инг вплоть до 32-64Мб, при максимуме в 320Гб...

        if (max_pfn < MB2PAGES(128))
                min_pages = MB2PAGES(8) + (max_pfn >> 1);
        else if (max_pfn < MB2PAGES(512))
                min_pages = MB2PAGES(40) + (max_pfn >> 2);
        else if (max_pfn < MB2PAGES(2048))
                min_pages = MB2PAGES(104) + (max_pfn >> 3);
        else
                min_pages = MB2PAGES(296) + (max_pfn >> 5);


Собственно, в комментариях уже выписано:

От 128 до 512 Мб лимит - одна вторая.
От 512 до 2Гб лимит - одна четверть (увы!)
От 2Гб до 8Гб - одна восьмая (т.е. минимум 360Мб)
От 8Гб до 32Гб - 1/32.
404

(no subject)

Интересно, насколько сложно пропатчить ядро domU в зене? Я нужное место уже нашёл, что писать знаю, теперь вопрос: как это всё собирается в deb...

Чувствую, мне всё-таки придётся освоиться с этим...
404

(задумчиво)

Знаете, в условиях малого офиса (6+ компьютеров, 1 сервер под SBS) и отсутствия адекватного мониторинга, использование для бэкапа принт-сервера (NAS на два винта с встроенным принт-сервером) - это очень важное стратегическое решение.

Если бэкапы не будут делаться, то об этом явно и недвусмысленно сообщат пользователи, у которых отвалилась печать.

(вопрос секьюрности решён банальным gpg на bkf перед копированием на бэкап-сервер).
404

дзен дзен дзен

Не могу нарадоваться на то, как оно чётко работает, после того, как я обстрипал всё лишнее и докопался до сути.

Теперь вопрос (теоретический).

Допустим, у нас есть скрипт, отрабатывающий раз в секунду/две/пять/десять (как скажут). Допустим, этот скрипт может попросить для ОС любой дополнительный объём памяти. Разумеется, он может посмотреть на текущее потребление памяти.

Вопрос: каким алгоритмом следует пользоваться, чтобы: а) не переесть памяти б) не словить oom_killer на следующей программе?

Вопрос исключительно про алгоритм, с его реализацией всё понятно.