ru.unix.bsd

 
 - RU.UNIX.BSD ------------------------------------------------------------------
 From : Valentin Davydov                     2:5020/400     03 Feb 2002  19:55:50
 To : Valentin Nechayev
 Subject : Re: своп
 -------------------------------------------------------------------------------- 
 

 >   From: Valentin Nechayev <netch@segfault.kiev.ua>
 >   Date: Sun, 3 Feb 2002 12:50:01 +0000 (UTC)
 >
 >> >Про связанное хранение данных всех VM objects в памяти кое-кто явно
 >> >не слышал.
 >> Верно, не слышал. Читал. В /sys/vm/vm*.{c,h} И про многоуровневые деревья
 >> хэшей там же читал, и даже про простые числа.
 >
 >Hу тогда должно быть понятно, что проитерировать все объекты и страницы
 >у них - операция скорее рутинная, нежели сложная.
 
 Вот именно. Для того, чтобы найти, кому принадлежит данная страница, 
 приходится бегать по всем процессам и у каждого спрашивать про каждый
 его allocated vm_object, не оно ли это. Вот в обратную сторону - да, 
 просто.
 
 >> >Дорогой тезка, выньте профильные затычки из ушей - в них ноты не пролазят.
 >> >Чтобы сделать swapoff грамотно, а не на тяп-ляп, нужен не swapoff(2),
 >> >а swapctl(2);
 >> Тогда уж sysctl vm.swap_не_только_enabled и пр.
 >
 >Я имел в виду управление свойствами каждого хранилища. Хотя бы - в какой
 >сейчас можно сбрасывать, а в какой уже нельзя, потому что он предназначен
 >на выключение. Через sysctl это не пойдет - там нету пока динамических
 >деревьев.
 
 Оно, во-первых, совсем не обязательно дерево, а может быть таблица, а
 во-вторых, вполне себе статическая, размером NSWAPDEV entries.
 
 >> >признаки для каждого раздела - можно в него свопить
 >> >сейчас или нет, а в идеале - swap coloring;
 >> А разве pg_color из vm_object для этого не годится?
 >
 >А алгоритм использования где? А где код перекладки в более близкие свопы,
 >если они освобождаются? ;)))
 
 Алгоритма использования нету. И код не написан. О чём я и писал в самом 
 начале треда. Кстати, код, IMHO, довольно тривиальный, для каждой страницы
 в расчищаемом свопе шлём её хозяину сигнал (SIGDANGER ?), по которому он
 либо подбирает своё барахло, либо падает нафиг, если не понимает о чём речь.
 Через 60 секунд не освободил - шлём девятку, этот код в ядре уже есть ;-)
 
 >> >средства постепенной выгрузки
 >> >с разумным rate limit (чтобы система работала в это время).
 >>
 >> Так и представляю себе "средства постепенной выгрузки с разумным rate limit"
 >> в применении к какой-нибудь Мозилле, которой сказали kill после того, как у
 >> ней больше половины свопа натекло виртуальной памяти. Безотносительно к
 >> swapoff.
 >
 >Это как раз понятно. kill съела - память прочистилась - выгружать в оперативку
 >или на другой своп эти страницы не надо. Лишь бы в локах не запутаться.
 
 Это как раз непонятно. Зачем он (Hетшкаф) минутами шуршит свопом (да-да,
 на 16-тиметровом ноутбуке именно минутами), когда всего-то и надо, что 
 сказать exit().
 
 Вал. Дав.
 
 --- ifmail v.2.15dev5
  * Origin: St. Petersburg State University (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор 

Тема:    Автор:    Дата:    своп   Alexey M. Kosorotov   29 Jan 2002 15:31:24   Re: своп   Oleg Koreshkov   29 Jan 2002 15:37:33   Re: своп   freeman@stc.gov.ua   29 Jan 2002 16:30:52   Re: своп   Valentin Davydov   31 Jan 2002 10:06:42   Re: своп   Valentin Nechayev   01 Feb 2002 10:49:47   Re: своп   Valentin Davydov   02 Feb 2002 13:04:39   Re: своп   Valentin Nechayev   03 Feb 2002 16:50:01   Re: своп   Valentin Davydov   03 Feb 2002 19:55:50   Re: своп   Valentin Nechayev   04 Feb 2002 00:41:35