Alexey Pechnikov -> [email protected] @ Thu, 13 Aug 2009 22:09:50 +0400:
>> AP> rdiff-backup запускается с точно таким же приоритетом, как и прочие >> AP> пользовательские процессы. Что же означает его "прожорливость"? Как >> AP> я понимаю, процессы с равным приоритетом получают равные ресурсы. С >> AP> какой стати очередь ожидающих процессов "стопорится", совсем не >> AP> ясно. >> >> Шедулер не решает задачу, которую невозможно решить :-) Шедулер устроен >> проще - процессы с равным приоритетом, _готовые к использованию >> процессора_, получают равные шансы отработать очередной CPU slice. А >> если процесс застрял внутри write(2), потому что запросов к диску дцать, >> и его запрос сейчас в очереди надцатый, а шина одна - он попадает в LA. >> Равно и если к очередному слайсу их оказалось трое желающих на два >> процессора (что, в общем, нормально, если один бурно работает - слайс >> штука не такая уж маленькая) - двум дадут, а третий попадет в LA. AP> А мне казалось, современные планировщики ввода-вывода на порядок AP> сложнее описанного :-) Правда, после перехода на ядра 2.6.x, AP> перестал отслеживать алгоритмы планировщиков и т.п., поскольку AP> просто какая-то лавина изменений идет. Но знаю, что планировщиков AP> ввода-вывода несколько и среди них есть весьма "навороченные". Планировщик ввода-вывода, который на порядок сложнее, сам с легкостью становится источником стопора :-) На самом деле планировщик _ввода-вывода_ в данном случае пытается решать задачу, в которой все альтернативы плохи, а компромисс хуже любой из альтернатив :-) Более-менее преимущество имеет как раз rdiff-backup, потому что он работает с диском более-менее последовательно, и именно его запросы удобнее всего компоновать вместе. -- Мне еще спать под рутом (С)энта -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
