« Отговор #98 -: Dec 08, 2011, 23:03 »
Не означава.
Първо "по-ново ядро" е много условно понятие. Има няколко дистрибуции, които могат да си позволят да си имат екип от maintainer-и на ядрото, дали заради наличие на финансови ресурси (Red Hat) или поради наличието на достатъчно голямо community (Debian). Тези хора имат задължението да подържат собствено kernel tree, да го patch-ват с разни security кръпки, да му добавят нова функционалност, да тестват. Идеята е че development процеса при stock ядрото е леко хаотичен, прекалено много готвачи, манджата не винаги става както трябва. Най-малкото тестовете там не са адекватни. Отделно, kernel developer-ите често не им пука толкова ако някоя промяна счупи определено множество userspace софтуер, но на хората, които подържат дистрибуции им пука. Така че никой не е казал, че примерно дебианското 2.6.32-5 е "по-старо" да речем от 2.6.35. Няма подходяща метрика за "старост" и "новост" в случая.
Второ, не е казано че "новите" ядра да водят до намалена производителност при стар хардуер. Когато новият софтуер работи по-бавно върху стар хардуер, обикновено проблемът е в userland-а, не в ядрото. Цялата
система е достатъчно много комплексна, за да може някой да плесне с ръце и да каже "това е по-бързо". Един и същ софтуер може да се държи радикално по-добре на по-нов хардуер, поради ред причини - примерно workset-а успява напълно да му се събере в кеша или пък е I/O интензивен и SATA2 му върши далеч по-добра работа от ATA. В един момент, авторът на програмата решил че може да вдигне някой лимит за големината на някоя структура от данни без това да се отрази на производителността, обаче на стар хардуер това се оказва фатално лоша идея, защото не се събира в кеша. Или пък решил, че може да опрости алгоритъма, увеличавайки обема на нещата, които пази върху диска, но спестявайки излишни сметки и фокуси - хората с бързи дискове не го усетили, хората с бавни дискове го усетили.
И накрая, взаимоотношенията между ядрото и приложния софтуер са относително ограничени като множество в сравнение с взаимоотношенията между отделните подсистеми и слоеве на приложния софтуер. Хората дето пишат kernel-а се стараят да подържат достатъчно малко "точки на взаимодействие" с приложния софтуер - например броя syscall-ове нараства доста бавно и интерфейсите за взаимодействие между приложния софтуер и драйверите често минава през някакъв стандартизиран интерфейс като например sysfs. Взаимодействията между отделните userspace софтуери обаче са далеч по-сложни и далеч по-често търпят корекции. Примерно Xorg е доста по-"обемен" проект от kernel-а с доста повече редове код, доста повече интерфейси между компонентите. Стандартната KDE среда е още по-комплексна кочина.
Дори на пръв поглед прости benchmark тестове от сорта на тези от phoronix са ужасно условни и включват прекалено много променливи. Силно те съветвам когато някой започне да те убеждава как нещо върви по-добре на някакъв хардуер, да не го приемаш на доверие. Просто човекът ти споделя някакви субективни наблюдения, твърде вероятно имате съвсем различни workload pattern-и. Това е ОК, но не означава, че същото ще е валидно в твоя случай.
