htop читается /proc. Вы можете это легко проверить, запустишь strace -fo htop.strace -s 1024 htop. Вы тормозов не видите, потому что у вас процессов мало. В критических ситуациях на больших серверах это становится реальной проблемой.
С другой стороны, мы убедились в том, что вопрос участия в подобных мероприятиях – дело настойчивости и уверенности в своем проекте. Если вам нужны разработчики, просто не уставайте подавать заявки и формулировать новые, интересные темы. Возможно, вы найдете на них совершенно неожиданных контрибьюторов из другой страны или даже из другой компании.
Я бы не согласился с этим выводом. Если вам нужны разработчики, то GSoC не ваш вариант. Не надо думать, что сейчас кто-то придет и все сделает. Работа со студентами будет отнимать время ваших разработчиков, а вот гарантий, что оно вернется в будущем, никаких нет.
К примеру, в данном случае, разработчики потратили времени на работу со студентами большем, чем если бы они делали эту работу сами. Но не все так просто. В данные момент, CRIU практически полностью разрабатываться людьми в свободное время. Денег им никто не платит и заставить их что-то делать, практически невозможно. Так что холодные расчеты времени тут не работали. Никто делать эту оптимизацию памяти не хотел, а вот желание поучаствовать в GSoC было.
Если смотреть в будущее, то есть вероятность, что студент останется в проекте и будет уже работать самостоятельно и приносить пользу. Такой пример у нас есть. Год назад, один из студентов GSoC внедрял CRIU в libvirt. Успешно завершив свой проект, он стал активным участником в CRIU сообществе и за последней год сделал многое для развития проекта.
И третий бонус, это разного рода статьи и привлечения внимания академического сообщества. Есть вероятность, что студент, познакомившись с проектом, дальше выстроит свою исследовательскую работу вокруг него. Такие примеры в нашей практике тоже есть.
Осталось понять, почему вы все еще просите бекпортов. Наверное продукт не так плох, как вы об этом кричали и это просто был такой странный метод привлечь внимание.
К слову, это открытый продукт, патчи в апстриме, и вы можете помочь забекпортить их. Это немного добавит в вашу подпорченую карму:).
Речь идет о первом варианте, обратную совместимость никто не отменял. В будущем, генерацию этих файлов из ядра можно будет перенести в user-space, что-то вроде fuse файловой системы, но тут надо еще думать.
И вы совершенно правы, вопрос о поддержке двух интерфейсов регулярно возникает. Сейчас код написан так, что большая его часть шарится между procfs и task_diag.
Это долгая история, изначально мы использовали netlink сокеты, но потом пришли к тому, что к транзакционному файлу в /proc/. На самом деле в /proc достаточно много бинарных файлов: /dev/mem/, /dev/kmem, /proc/pid/pagemap, etc. В чем абсурдность идеи? Как вы бы это сделали?
Про какие бы новые фишки в Linux мы не говорили, всегда кто-то скажет, что в Солярис все это было. Остается только один вопрос: «Почему не стало соляриса?». Судя по всему, это была ОС, которая сильно обогнала свое время.
> Вы предлагаете (2). Дело ваше — спорить не буду.
В вашем примере, я как раз выбираю первый вариант. А второй вариант — это то как сейчас работает ps или top. Сначала ядро данные о процессах выдает в текстовом виде, потому утилита ps декодирует их к бинарному виду, обрабатывает и выдает в другом текстовом виде.
Во-первых, текущий /proc еще долго никуда не денется, обратную совместимость никто ломать не даст. Даже если его когда-то решат выкинуть из ядра, то появится fuse файловая система, которая будет выглядеть как /proc.
Во-вторых, если вы говорите про grep, sed, awk и тп, то вы уже готовы запускать дополнительные процессы, а значит сможете запустить и дополнительную тулзу, которая выдаст вам нужные данные, полученные через новый интерфейс.
В-третьих, если мы идем чуть дальше и вместо shell начинаем использовать что-то вроде python, то с новым интерфейсом вам жить будет даже проще.
По поводу количества процессов. Если у вас речь идет о десятках процессов, то действительно проблем нет и с текущим интерфейсом.
Я все же предлагаю сравнить производительность task_diag и procfs для большого количества процессов.
Для эксперимента, я опять запустил 10000 процессов. Давайте теперь посмотрим сколько будет выполняться приведенный вами скрипт и получение тех же данных через task-diag.
# time for i in /proc/*/stat; do read STAT < $i; done
-bash: read: read error: 0: Is a directory
real 0m0.657s
user 0m0.138s
sys 0m0.515s
А теперь получим cputime через task_diag:
# time ./task_diag_all all -x -q
real 0m0.041s
user 0m0.000s
sys 0m0.039s
Для понимания, вот пример данных, которые мы получаем через task_diag:
Да, с шельным скриптом я не додумал, точне я забыл про команду read. Тут вы правы, можно сделать быстрее.
Про то что ваш скрипт станет немного медленнее из-за лишнего форка, тут вы просто свой скрипт перепишите на python или любом другом языке, который сможет напрямую работать с новым интерфейсом и все будет хорошо.
Наверняка, вам в вашем плагине нужно получать cputime для всех процессов в системе. А теперь задумайтесь, сколько это займет времени, если это делать из шел скрипта.
Я провел небольшой эксперимент. Запустил 10000 процессов и запустил следующую команду:
# ps ax | wc -l
10091
# time for i in /proc/*/stat; do cat $i > /dev/null; done
cat: /proc/net/stat: Is a directory
real 0m21.923s
user 0m2.326s
sys 0m19.934s
20 секунд на 50K процессов. Имхо, это очень много.
Сейчас никак, но если в ядре появится что-то похожее на task-diag с бинарным форматом, то так же появится и пользовательская команда, которая будет выводить нужную для пользователя информацию с той же точностью, которую предоставляет ядро.
Описание проблемы с сигналами не совсем точное. Нас в первую очередь интересовали сигналы, которые стоят в очереди в тот момент когда мы цепляемся к процессу. Сигналы, которые присылаются во время препарирования, скорей всего, и сейчас будут вызывать некоторые проблемы, т к ptrace на них реагирует даже когда они заблокированы. Это небольшая проблема для criu, но достаточно серьезная проблема для живого патчинга.
Не, не. Это никак не объясняет почему оно не работает. В первую очередь надо сообщить о проблеме, а там уже решать, кто это будет чинить. Если мы видим, что проблема частая, то мы ее стараемся закрыть, даже если она не в CRIU.
htop читается /proc. Вы можете это легко проверить, запустишь strace -fo htop.strace -s 1024 htop. Вы тормозов не видите, потому что у вас процессов мало. В критических ситуациях на больших серверах это становится реальной проблемой.
Я бы не согласился с этим выводом. Если вам нужны разработчики, то GSoC не ваш вариант. Не надо думать, что сейчас кто-то придет и все сделает. Работа со студентами будет отнимать время ваших разработчиков, а вот гарантий, что оно вернется в будущем, никаких нет.
К примеру, в данном случае, разработчики потратили времени на работу со студентами большем, чем если бы они делали эту работу сами. Но не все так просто. В данные момент, CRIU практически полностью разрабатываться людьми в свободное время. Денег им никто не платит и заставить их что-то делать, практически невозможно. Так что холодные расчеты времени тут не работали. Никто делать эту оптимизацию памяти не хотел, а вот желание поучаствовать в GSoC было.
Если смотреть в будущее, то есть вероятность, что студент останется в проекте и будет уже работать самостоятельно и приносить пользу. Такой пример у нас есть. Год назад, один из студентов GSoC внедрял CRIU в libvirt. Успешно завершив свой проект, он стал активным участником в CRIU сообществе и за последней год сделал многое для развития проекта.
И третий бонус, это разного рода статьи и привлечения внимания академического сообщества. Есть вероятность, что студент, познакомившись с проектом, дальше выстроит свою исследовательскую работу вокруг него. Такие примеры в нашей практике тоже есть.
К сожалению, второй студент не справился с задачей и патчи не были приняты.
К слову, это открытый продукт, патчи в апстриме, и вы можете помочь забекпортить их. Это немного добавит в вашу подпорченую карму:).
k001.livejournal.com/819624.html
И вы совершенно правы, вопрос о поддержке двух интерфейсов регулярно возникает. Сейчас код написан так, что большая его часть шарится между procfs и task_diag.
Смените тон и прочтите еще раз коментарий.
> Вы предлагаете (2). Дело ваше — спорить не буду.
В вашем примере, я как раз выбираю первый вариант. А второй вариант — это то как сейчас работает ps или top. Сначала ядро данные о процессах выдает в текстовом виде, потому утилита ps декодирует их к бинарному виду, обрабатывает и выдает в другом текстовом виде.
Во-вторых, если вы говорите про grep, sed, awk и тп, то вы уже готовы запускать дополнительные процессы, а значит сможете запустить и дополнительную тулзу, которая выдаст вам нужные данные, полученные через новый интерфейс.
В-третьих, если мы идем чуть дальше и вместо shell начинаем использовать что-то вроде python, то с новым интерфейсом вам жить будет даже проще.
По поводу количества процессов. Если у вас речь идет о десятках процессов, то действительно проблем нет и с текущим интерфейсом.
Я все же предлагаю сравнить производительность task_diag и procfs для большого количества процессов.
Для эксперимента, я опять запустил 10000 процессов. Давайте теперь посмотрим сколько будет выполняться приведенный вами скрипт и получение тех же данных через task-diag.
А теперь получим cputime через task_diag:
Для понимания, вот пример данных, которые мы получаем через task_diag:
Про то что ваш скрипт станет немного медленнее из-за лишнего форка, тут вы просто свой скрипт перепишите на python или любом другом языке, который сможет напрямую работать с новым интерфейсом и все будет хорошо.
Я провел небольшой эксперимент. Запустил 10000 процессов и запустил следующую команду:
# ps ax | wc -l
10091
# time for i in /proc/*/stat; do cat $i > /dev/null; done
cat: /proc/net/stat: Is a directory
real 0m21.923s
user 0m2.326s
sys 0m19.934s
20 секунд на 50K процессов. Имхо, это очень много.