Как другие процессы могут влиять на измерения, сделанные со 'временем'?
Давайте очистим его немного и сделаем его более портативным. В целом, лучше использовать tput генерировать управляющие последовательности вместо трудного кодирования их, как описано в Bash FAQ 53. Таким образом, намного легче найти Ваших пропавших без вести \].
red=$(tput setaf 1)
green=$(tput setaf 2)
yellow=$(tput setaf 3)
white=$(tput setaf 7)
reset=$(tput sgr0)
PS1="\[$red\][\[$yellow\]\A\[$red\]] \u:\[$green\]\W\[$white\]\$\[$reset\] "
Обратите внимание, что я заменил Ваш date вызов со встроенным быстрым Escape \A это отображает то же самое (24-часовое время в HH:MM формат).
Существует один протест с этим подходом, как описано в связанном Bash FAQ, где вывод был бы искажен если любой из tput управляющие последовательности производят что-то, что, оказалось, содержало быстрый Escape. Я никогда не сталкивался с той проблемой, таким образом, я обычно игнорирую ее.
Нет. Процесс/контекстные переключения не является бесплатным.
Сколько замедлит другое выполнение процессов, Ваш вниз очень системно-зависим, но оно состоит из вещей как:
Каждый раз переключения процессора к различному адресному пространству (включая процесс), затем кэш MMU должен быть сброшен. И вероятно кэши процессора L1. И возможно L2 и кэши L3. Это замедлит доступ к памяти прямо после того, как Ваш процесс будет возобновлен (и это говорит против Вашего "пользовательского" времени).
На SMP (или многоядерный) должно сотрудничать поле, если два процесса пытаются получить доступ к тем же частям (физической) RAM, процессоры. Это занимает время. Это часто делается на уровне архитектуры даже ниже ОС. Это будет говорить против Вашего пользователя или sys время, в зависимости от того, когда оно совершило нападки.
Быстрая блокировка ядра (который на самом деле не планирует другой процесс) будет говорить против Вашего sys времени. Это подобно точке выше.
на полях NUMA Вы можете быть перемещены в другой узел. Доступ к памяти может теперь быть междоменным, и таким образом медленнее
другие процессы могут влиять на решения управления питанием. Например, привязка большего количества ядер уменьшит скорости Intel Turbo Boost, для хранения корпуса процессора в его электрических и тепловых спецификациях. Даже без турбо повышения, процессор можно замедлить из-за избытка тепла. Это может работать другой слишком — больше загрузки может заставить регулятор скорости ЦП увеличивать скорость ЦП.
В системе существуют другие совместно используемые ресурсы; если ожидание их на самом деле не включит Ваш сон процесса, то это будет говориться против Ваш пользователь или sys время.
Это подразумевает, что 'пользователь' и 'sys' будут незатронуты другими процессами?
user время не может действительно быть затронуто ничем больше непосредственно. sys время может, так как оно может включать ввод-вывод. Если существует набор процессов, пытающихся получить доступ к устройству сразу, само устройство может стать занятым, таким, что, когда Ваш процесс активно планируется, система должна ожидать на устройстве. Это не должно составлять очень, потому что ожидание главным образом пассивно - добавляющий к real время - но если это включает повторенный опрос, это активно.
sched_setschedulerсSCHED_FIFOи высокий приоритет. Это должно в значительной степени остановить все остальное, по крайней мере, в одножильной системе. Но я думаю, что это лучше всего спросили бы как новый вопрос, наряду с деталями. – derobert 19.12.2013, 19:18