В документе "Secretly Monopolizing the CPU Without Superuser Privileges (http://www.cs.huji.ac.il/~dants/papers/Cheat07Security.pdf)" описан способ создания приложения на 100% утилизирующего процессорные ресурсы, будучи запущенным с привилегиями обычного пользователя.

Изюминка метода - полная загрузка CPU в некоторых ситуациях не прослеживается стандартными утилитами мониторинга, например, в top перегрузка не видна.

Проблеме подвержены планировщики задач Linux, Windows, Solaris, FreeBSD. Исключение составляет Mac OS X и планировщик CFS который появится в 2.6.23 Linux ядре.

URL: http://it.slashdot.org/article.pl?sid=07/07/11/1421209&from=rss
Новость: http://www.opennet.me/opennews/art.shtml?num=11404

• Метод невидимой монополизации CPU пользовательским приложени...,moo, 00:02 , 14-Июл-07
  • Метод невидимой монополизации CPU пользовательским приложени...,vp, 22:51 , 14-Июл-07
    • Метод невидимой монополизации CPU пользовательским приложени...,moo, 00:42 , 15-Июл-07
      • Метод невидимой монополизации CPU пользовательским приложени...,Keks 007, 05:39 , 15-Июл-07
        • Метод невидимой монополизации CPU пользовательским приложени...,Antrew, 04:56 , 16-Июл-07
          • Метод невидимой монополизации CPU пользовательским приложени...,Кекс07, 11:13 , 17-Июл-07
            • Метод невидимой монополизации CPU пользовательским приложени...,Аноним, 21:57 , 17-Июл-07
  • Метод невидимой монополизации CPU пользовательским приложени...,MiG, 01:20 , 15-Июл-07
• Метод невидимой монополизации CPU пользовательским приложением,AMDmi3, 16:32 , 16-Июл-07
  • Метод невидимой монополизации CPU пользовательским приложени...,AMDmi3, 16:51 , 16-Июл-07

Планировшики тут не при чём, все выше перечисленные
операционные системы/ядра (за исключением может быть
Solaris) собирают информацию по учёту времени не
корректно, и как следствие возможны подвохи.

Documentation/cpu-load.txt

Я чего-то недопонял. Ведь планировщик же потом учитывая эту информацию совершает определённые действия: например изменяет приоритет. Ведь на этом же игра идёт. Что потом будет иметь высокий приоритет и ему каждый тик будут передавать управление.
moo, что ты имел ввиду?

Планировшик Линукса эту информацию не использует вообще, она
хранится исключительно ради того чтобы ктото мог её прочитать
(через /proc например). Что делает Windows, Solaris, MacOSX я не
знаю.

http://lkml.org/lkml/2007/2/13/314

>Планировшик Линукса эту информацию не использует вообще, она
>хранится исключительно ради того чтобы ктото мог её прочитать
Эээ, типа, предлагаете предоставить системе самой решать какой приоритет у каких задач должен быть?Круто, тогда следующим шагом надо еще научить систему обходиться без юзера - да здравствуют терминаторы, слава роботам :)

кекс, запусти top и обрати внимание что есть nice level, а есть priority

>кекс, запусти top и обрати внимание что есть nice level, а есть
>priority
Секунду, а что, сегодня система уже всегда за меня решает какой приоритет кому выдать правильнее?Чего-то я не заметил - если мне надо, могу сам указать, вроде.Меня где-то на__али? :)

мдя полное отсутствие знаний мат части

Так это тоже задача планировщика - правильно учесть время отработанное потоком. :)

Хм, работает, притом отлично. Одна и та-же задача просто в цикле и с описанным способом с отжиранием 0.9 тика:

time ./plain
2.53user 0.00system 0:02.55elapsed 99%CPU
time ./cheat
0.04user 0.00system 0:04.96elapsed 0%CPU

Ubuntu шестая, Core 2 duo.

Как видно, оверхед много больше 10%. Учитывая, что вычисления у меня на каждой итерации явно много тяжелее rdtsc, вычитания и сравнения, дело таки в шедулере. Видимо следующий тик мой процесс таки пропускает. Как бы то ни было, пора сваливать с виртуального хостинга :)

А, не, туплю. Приличное время еще занимает cycles_per_tick(). Т.е. оверхед таки невелик.