1.1, Nick (??), 18:35, 11/10/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
ну, красота :)
что сказать... вещь
и вещь отданная под GPL'ем...
было бы любопытно взглянуть на тесты .23 ядра со срезами BSDшных высот
| |
|
2.3, Nick (??), 19:07, 11/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
для начала неплохо
но вобщем-то желательно не release candidat рассматривать
и в ванильном виде (не знаю чего там Федора подмешала)
| |
2.7, sauron (??), 21:17, 11/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
Ага только вот там про огрехи gnu glibc malloc промолчали. Несколькими новостями ниже есть сравнение ядра linux с tcalloc. Там график ровнее.
| |
|
1.6, Аноним (2), 20:43, 11/10/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А трехкратное падение производительности для одного клиента это типа нормально? Зато OMFG, теперь мы на 20% меньше тупим на десятке клиентов.
| |
|
|
Часть нити удалена модератором |
3.25, Аноним (-), 14:06, 12/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
посмотри начало графиков
в первой точке, которая соответствует 1 клиенту, транзакций в .23 меньше в 3 раза
| |
|
4.26, anonymous (??), 14:28, 12/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
На графиках количество транзакций в секунду не от нуля начинается, а от 400.
Так что падение не в три раза, а где-то на 20 процентов (что тоже не очень радует).
| |
|
|
6.32, _Nick_ (??), 03:48, 13/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
да расслабьтесь
системе с один запросом в единицу времени пофик производительность ЗАЧАСТУЮ
Интересны именно паралельные запросы.
Так что даже если пере Инго стоял выбор - он его сделал верно.
| |
|
|
|
|
|
1.12, pavlinux (??), 22:14, 11/10/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Все уроды, я the best !!!
Ладно, по делу:
> ... and i'm definitely interested in more
> feedback about this:
asmlinkage long sys_time(time_t __user * tloc)
{
- time_t i;
- struct timespec tv;
-
- getnstimeofday(&tv);
- i = tv.tv_sec;
+ time_t i = get_seconds();
| |
|
|
3.35, Аноним (2), 01:50, 15/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Хотя, может на VAX или на ARM get_seconds() не работает???
Эй, мокрый куриц, а на мипс?
| |
|
|
1.15, Ромка (?), 23:21, 11/10/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Господа, а какой подскажет какой утилиткой такие графички рисуются? Неужтно gnuplot'ом?
| |
|
2.16, pavlinux (??), 23:49, 11/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
Да ты так не пугайся gnuplot_a, часика три помучаешся, потом понравиться!
| |
|
1.22, Аноним (22), 13:16, 12/10/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
а кто знает, почему в новое ядро не включают tcmalloc, вместо обычного malloc'а?
| |
|
|
3.24, Аноним (-), 13:43, 12/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
точно, глупость сказал, сорри.
не знаете, почему в glibc его не включают?
| |
|
4.29, Аноним (-), 16:04, 12/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
У него есть свои недостатки.
Например (пока) он не возвращает память операционной системе.
Как стандартный аллокатор назначения он не годится.
Многопоточные программы, постоянно выделяющие/освобождающие память легко могут его использовать вместо стандартного. Остальные программы нечего ломать :)
| |
|
|
|
1.27, fresco (??), 14:56, 12/10/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Кроме прочего, в 2.6.23 добавились усовершенствования производительности в read ahead, reiserfs и XFS. Тоже, ИМХО, немаловажные штучки в плане быстродействия всей системы. Хотя в контексте этого теста они, конечно, не так чувствуются.
| |
1.31, pavlinux (??), 23:25, 12/10/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Не успели обругать.... как 2.6.23.1 надворе. :)
libata: sata_mv: more S/G fixes
* corruption fix: we only want the lower 16 bits of length (0 == 64kb)
* ditto: the upper layer sets max-phys-segments to LIBATA_MAX_PRD, so we must reset it to own
hw-specific length.
* delete unused mv_fill_sg() return value.
| |
|
2.37, Nick (??), 02:00, 15/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
ИМХО
в не-RT ядре прерывания нужно обрабатывать сразу, по мере их появления.
За сим, любой свободный проц чудно подходит для этого.
А в ядре, где для прерываний свои очереди выполнения имеют - их можно и отложить, выпонив на одном проце. Именно на одном, видать, по кешу выгодно.
| |
|
|