недогружается проц
вобщем в чем прикол, проц грузится на 10-20% главное прикол в том что работается даже очень неплохо пока не запустиш чето "тяжелое" сопсно поетому раньше внимания не обрасчал, началось с того что я захотел в Морровинд под вайном поигратся, даж тут создавал тему по поводу того что тормозит, ниче не помогло+ на вайновском сайте написано что ето глюк морра, он хронически тормозит под вайном, думаю ну да ладно,, но вот снова вернулся к етому, дали ВОВ, он выдает 4-5фпс-а против виндовых 30+ силно огорчило, вот теперь начал тестить ето безобразие, последние пару дней шаманил с ядром, нифига не помогло, причем запускал виртуал бокс, он с радостью сжирал весь простой проца, а система ето слабо замечала, glxgears грузит проц дет на половину.., короче фигня какаята. Ктонибудь может подсказать в чем дело?, я всеже думаю на ядро, ктонить выложите плиз нормальный конфиг для ядра 2.6.23 или новее. Может и не в ядре дело но хочу всеже убедится.
- Для комментирования войдите или зарегистрируйтесь
а при сборке на
а при сборке на сколько грузится?
__
тоже на 10-20, иногда до 30% подскакивает.
Так а какой
Так а какой проц? Core Quad?
__
проц древненький)
dan@localhost ~ $ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Celeron(R) CPU 2.00GHz
stepping : 9
cpu MHz : 1992.698
cache size : 128 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe up pebs bts sync_rdtsc cid xtpr
bogomips : 3988.19
clflush size : 64
CONFIG_GROUP_SCHED=y ?
$ uname -r
$ grep GROUP /usr/src/linux/.config
Вывод в студию.
__
с шедулерами я с самого начала шаманил, щас сижу на конфиге который genkernel сгенерил, думал мож поможет, оппа хаха, а токачто посмотрел конфиг на наличие CONFIG_FAIR_USER_SCHED, который мне когдато говорили отрубить но его упорно небыло в конфиге, хм полтергейст, наверно женкернел ето дело исправил, щас попробую отрубить и перекомпилится, мож вопрос отпадет сам собой...
а вывод вот, да новый шедулер включен, знаю:)
uname -r
2.6.24-gentoo-r8
grep GROUP /usr/src/linux/.config
# CONFIG_CGROUPS is not set
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_FAIR_CGROUP_SCHED is not set
__
хм, просто поставил етим параметрам =n и запустил make, паралельно посмотрел конфиг, они исчезли... че за фигня, если их нету то считаются что не выбранные? вроде так они ж насколько помню #ifdef-ом проверяются в исходниках, или может есть нюансы?
Если опции не
Если опции не вкдючены, то в .config это отмечается как
# CONFIG_GROUP_SCHED is not set
Как конкретно этот .config парсится я не знаю, но даже если предположить, что конструкции переводятся в банальные #define, #ifdef, то никаких противоречий здесь не вижу. Закоментирована опция - не будет дефайна. Всё работает как нужно.
__
перекомпилил,,, 0 реакции как и ожидалось.. ток SMP забыл вырубить, но думаю ет не изза него
localhost dan # uname -a
Linux localhost 2.6.24-gentoo-r8 #4 SMP PREEMPT Sat Jun 28 16:45:08 EEST 2008 i686 Intel(R) Celeron(R) CPU 2.00GHz GenuineIntel GNU/Linux
вот так вот печально, может есть еще идеи? мож ето не изза ядра, хотя понятия не имею изза чего тогда...
Могу в
Могу в понедельник дать для подобного Келерона свой конфиг. Только у меня amd64 и ядро .25-е. Или хоть сейчас, x86 и .24, но на Келероне 666 (-:Е
Пожалуйста, не описывайте своё железо в подписи
__
пасиб но я кажысь уже нашел в чем беда:)
__
а всеже конфиг хотелось бы посмотреть:)
Так который?
Так который? (-:Е
Пожалуйста, не описывайте своё железо в подписи
__
"и того и другого и побольше" :-D
Тот, что amd64,
Тот, что amd64, будет завтра, а x86 — разве что послезавтра, если не забуду
Пожалуйста, не описывайте своё железо в подписи
Есть идея
Есть идея отказаться от genkernel и пересобрать ядро ручками, вдумчиво читая описания каждой опции ядра. Ибо все симптомы указывают на работу fair group scheduler.
__
я всегда его ручками србирал,, вдумчиво B-) ток уже от иссякания фантазии по теме "что ж там еще можно поменять" решил поюзать женкернел, авось правильно замутит, но увы, не судьба:)
__
хаха, кажется наконец нашел в чем баг, http://bugs.gentoo.org/show_bug.cgi?id=228263, попробую откатить glibc...
Вообще вряд
Вообще вряд ли... Там и VIA, и проявления не совсем те. Опять же, у меня везде glibc 2.6.1, всё путём. Ну попробуй, жалко, что ли... Вот, правда, геморрою может выскочить много с откатом glibc...
Пожалуйста, не описывайте своё железо в подписи
__
ето да, ВИА, но симптомы чемто похожи, вдруг поможет, кстати оффтоп но както можно емержу сказать чтоб он бинарный пакет замутил но не перекомпиливая все заново, а собрав то что поставлено в системе? ато хочу 2.6.1 жлибс забэкапить чтоб если не в нем проблема его быстро на место вернуть..
__
ууу
* Sanity check to keep you from breaking your system:
* Downgrading glibc is not supported and a sure way to destruction
*
* ERROR: sys-libs/glibc-2.5-r4 failed.
* Call stack:
* ebuild.sh, line 49: Called pkg_setup
* glibc-2.5-r4.ebuild, line 1077: Called die
* The specific snippet of code:
* die "aborting to save your system"
* The die message:
* aborting to save your system
*
* If you need support, post the topmost build error, and the call stack if relevant.
* A complete build log is located at '/var/tmp/portage/sys-libs/glibc-2.5-r4/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/sys-libs/glibc-2.5-r4/temp/die.env'.
*
ладно, тогда полезем в ~x86