В сообщении от 12 Апрель 2006 13:20 Dmitry E. Oboukhov написал(a): > сейчас структурно сделано примерн следующий алгоритм: > > 0. стартовые параметры: > 0.1 имеем блок-буффер равный размеру выходного файла (N байт) > 0.2 имеем процесс читающий устройство > > 1. читаем данные из устройства до заполнения буфера (N байт) > 2. форкаемся > 3. родитель переходит к п.1 > 4. дочка записывает данные в файл (БД) > 5. дочка завершает работу > > у устройства выходные буферы небольшие, если не форкаться, то мы теряем > данные на шаге 2. > данные идут с разной скоростью, иногда скорость превышает скорость > записи на диск (но интегральная скорость cущественно меньше), поэтому > надежность системы обеспечена количеством ОЗУ (то есть ОЗУ надо выбрать > столько чтобы в него помещались данные когда они идут большими дозами) > > вот теперь я думаю как оптимизировать алгоритм > > насколько я понимаю на шагах 2-3-4 система будет делать копирование данных > в памяти, поскольку родитель начал уже использовать тот же блок который > дочка пишет в БД/файл. > > как можно избежать копирования? Может использовать thread'ы, а не форкаться? Как бы тут на них не ругались, что они не вписываются в архитектуру Unix, но работать с ними можно всё-таки.
Кроме того, возможно у тебя ещё происходит копирование из kernel-space в user-space. Если ты можешь править драйвер, но покури доку, кажется, на relayfs - его, по-моему, как раз придумали для того, чтобы этого избежать. > и вообще насколько [не]эффективной > представляется данная структура алгоритма специалистам? если делать в > каждом цикле запрос блока памяти у системы и возврат ее обратно то как > будет выглядеть (фрагментирована) память у основного родителя через > некоторое время работы? где об этом можно почитать? > > > PS: смотрел я как работает система - максимум дочек накапливается около > 20 штук, то есть скорость потока "пляшет", однако интегральный запас ОЗУ > получается очень большим. В принципе, я думаю, что можно обойтись двумя нитями, одна читает, другая пишет. -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
