>Большой респект автору патча!
>Я тоже планировал поработать над этим,только руки еще не дошли. счас расковыриваю
>jail, надо сделать:
>1. лимит юзания проца, но не жесткий,скажем 40% итп,а приоритетливый,те юзать свободное
>процессорное время,вернее хавать времени чуть-чуть(выставляется),а остальное,если есть свободное.
тут вариантов по сути не много, самый простой и добавлящий неплохо оверхеад - это счетчик который накапливает использование CPU за HZ - и потом скипает треды в точке выбора.
просто - но когда у тебя много процессов в очереди на выполнение - не экономно.
более интересный вариант или лоторейный или fair share шедулеры - они заменяют собой 44BSD или ULE (и его доработку от Давида Ксю) на свой - тут можно добиться практически O(1). для примера можно глянуть как это сделано в OpenVZ или поискать наработки для 4.x/5.x по лоторейному шедулеру.>2. лимит рамы. тут уже жестко. 2мб,значит 2 :)
а вот тут определись какой рамы:
1) address space
2) resident size
3) resident + swap
4) реально аллоцированные странички памяти - с учетом того что память может шариться между задачами?
>это все должно действовать на весь jail целиком,без разбору,в сумме. и плюс
>в нутри каждого jail-а могут работать свои login.conf лимиты.
>ну и виртуального рута,отмапленого на хостовой системе,скажем на nobody или выборочно на
>какой-то uid для каждого jail отдельно.
аха. в jail2 это уже давно есть. называется разделение uid hash.
>И еще жесткие лимиты распространить на root-а на хостовой системе,чтобы при определенной
>sysctl, равной 1(и ее нельзя декрейсить,подобно kern.securelevel,по умолчанию 0,но можно инкрейсить)
>нельзя было увиличить себе rlimit,только уменьшить.
есть в jail2. rlimit ты можешь выставлять что угодно - а то что выставлено для контекста будет проверяться раньше.
>Есть какай-то реализация в perforce, jail2 называется,но я ее не копал
;)
