Вот как раз это и не маразм. На сетевой карточке очень логично выполнять часть/полностью ip (и более высоких уровней) стека. Так же как в дисковом контроллере сделать поддержку файловой системы. Тогда ядро обращалось бы к дисковому контроллеру не как к интерфейсу для записи/чтения последовательности блоков, а как к сервису файлов. Точно так же в видеокарту логично вынести библиотеки уровня Gtk/Qt/wx, и сделать этот сервис доступным и из ядра и из пользовательских програм. Но все это - хорошо забытое старое, вперед к менфреймам.

>огромную силу [...] процессоров

И что, процессоры нынче очень сильные стали?

GPU_NAT !

Идея гениальная, но наверное имело бы смысл сначала переписать драйвер zfs, тот который под fuse писан, так что бы он GPU при расчете хэшей использовал. Боюсь, что в таком случае, профит будет колоссальный, по скорости такое решение может обойти даже внутриядерные реализации.

>сначала переписать драйвер zfs, тот который под fuse писан, так что бы он GPU при расчете хэшей использовал

а на CPU оптимизировать слабо?

>Что тебе ещё из «концепции микроядра» не хватает?

Возможности написать драйвер видеокарты в user-space.

3) Из ядра линукс можно вызывать юзерспейсный код

Что ты под этим имеешь ввиду?

Palit GeForce GTX 590 607Mhz PCI-E 2.0 Технические характеристики Частота графического процессора   607 МГц Частота шейдерных блоков   1215 МГц Объем видеопамяти   3072 Мб Тип видеопамяти   GDDR5 Частота видеопамяти   3414 МГц Разрядность шины видеопамяти   768 бит Частота RAMDAC   400 МГц Математический блок Число универсальных процессоров   1024

Давай, оптимизируй на проце, хоть на восьмиядерном. Исход и так понятен.

offtop: Дядь, а приведи пример какой-нибудь б/м востребованной штуки, где бы применялся CUSE. Не троллинга ради, а для саморазвития.

>Исход и так понятен.

Читай мой пост выше - с таким подходом («на оптимизацию - класть!») и этой видюхи не хватит

>Возможности написать драйвер видеокарты в user-space.

man Xorg

Что ты под этим имеешь ввиду?

Только то, что написал

>>Возможности написать драйвер видеокарты в user-space.

man Xorg

А ядерная часть дров за дрова уже не считается?

Только то, что написал

Это даже при всем желании не покритикуешь :)

Пусть лучше помогут Столлману допилить ядро

Неправильный подход...

Лучше бы задумались про ускорение графического процессора (GPU) с помощью ядра GNU/Linux. Nuff said.

А без ядерной части долгое время обходились. Да и сейчас она нужна, по большому счёту, как постоянно загруженный сервис, не зависящий от иксов. Ну крутится оно не отдельным демоном, а в ядре...

>И что, процессоры нынче очень сильные стали?

А ты думал? В рывке под 85кг уже тягают.

По теме - слегка боязно оно все. Потом в ядре будут «240GT module, 220GT module, ###GT module»... Раздуется оно мощно, да и с переносом между машинами большие проблемы будут

>А без ядерной части долгое время обходились.

На другой планете

Да и сейчас она нужна, по большому счёту, как постоянно загруженный сервис, не зависящий от иксов.

Ядерная часть не зависит от Иксов — ты раскрыл большой секрет :)

Ну крутится оно не отдельным демоном, а в ядре...

Ядерная часть «крутится» в ядре — с этим не поспоришь, кэп.

Как нубовским способом Wayland попробовать, кстати?

>Как нубовским способом Wayland попробовать, кстати?

http://wayland.freedesktop.org/building.html

В виртуалке

> Идея гениальная, но наверное имело бы смысл сначала переписать драйвер zfs, тот который под fuse писан, так что бы он GPU при расчете хэшей использовал. Боюсь, что в таком случае, профит будет колоссальный, по скорости такое решение может обойти даже внутриядерные реализации.

Может быть, но только в том случае, если ты SHA256 для всего используешь. Да и то есть сомнения в «колоссальности» профита.

> Ненужные жуткие костыли: ядро общается само с собой через юзерспейсный софт

А нельзя ли напрямую из ядра «общаться» с процессорными элементами сетевухи, видюхи и т. д.?

> Господа, вспоминаем про разработку CPU с GPU в одном флаконе.

Я против подобных агрегатов. Когда весь комп разбить на модули - проц, мамка, сетевуха, wimax-карта и т. д., еще можно терпеть проприетарность отдельных модульных драйверов типа BLOB от nvidia. А когда мы имеем единый девайс, в котором и оператива, и проц, и видюха, и сеть (чего доброго) - не будет он работать без проприетарного блоба. Печаль.

ЛОР, что делать?

> Здесь весьма кстати была бы концепция микроядра

Танненбаум просрал спор. Его Minix юзает два с половиной человека. А линукс...

http://keinkeinkein.livejournal.com/54456.html
http://keinkeinkein.livejournal.com/57295.html

Всё к этому идет, а когда придут армы у которых на одном кристалле вообще всё и каждый производитель затачивает этот кристалл под себя вообще будет жопа. Никакого линуха на компах не будет или будет, но анально огороженный как сейчас на андроид-устройствах.

> А в ядре разве есть большое количество чистых вычислений?

«В подтверждение авторы KGPU создали реализацию алгоритма AES, которая позволила поднять скорость шифрования файловой системы eCryptfs в 6 раз.»

http://www.opennet.ru/opennews/art.shtml?num=30484

Лихое дело - начало

Почему бы и не перенести некоторые модули и демоны на ГПУ? Для пользовательских программ останется больше ресурсов процессора. Пусть получится небольшой прирост производительности, но хоть какой-то. Если не будет работать на АМД, то в топку.

>Тогда ядро обращалось бы к дисковому контроллеру не как к интерфейсу для записи/чтения последовательности блоков, а как к сервису файлов.

к сожалению, чем выше уровень интерфейса подсистемы, тем он сложнее, причем в геометрической прогрессии.

Все эти акселераторы оттого и вымерли, что сложные, дорогие и глючные.

Даже в простейшем файловом акселераторе непонятно, как включать новые файловые системы, дефрагментацию и восстановление данных, ресайз и другие служебные вещи, mmap и т.д.

>Почему бы и не перенести некоторые модули и демоны на ГПУ?

потому что прирост будет отрицательный. Почему изначально видеокарта? Потому что можно взять некий небольшой блоб инструкций, скопировать его в буфер и махнуть палочкой - работай! И оно автономно раскрывается в виде картинки на мониторе.

И совсем другое - демон, который шуршит диском полчаса, а потом тупо складывает два столбца интежеров и опять шуршит винтом, чтобы загнать все обратно. Какие тут нафиг ускорения?

>ускорить части ядра Linux запустив его прямо на GPU

Какой хитрый способ избавиться наконец от ненавистного своим разработчикам X-сервера.

http://sourceforge.net/projects/osspd/

>А ядерная часть дров за дрова уже не считается?

Считается. Но я же не зря тебе сказал:

man Xorg

Подсказка: покажи «ядерную часть» для Xorg'овского драйвера nv

>а когда придут армы у которых на одном кристалле вообще всё и каждый производитель затачивает этот кристалл под себя вообще будет жопа. Никакого линуха на компах не будет

Ага. А сейчас на армах только кастрированный недо-iOS и полумёртвый WinMobile - и никакх «линухов»!:)

анально огороженный как сейчас на андроид-устройствах

А на «андроид-устройствах» - не «линух»? А что? Просвети нас, толстячок,

>покажи «ядерную часть» для Xorg'овского драйвера nv

drivers/video/fb.c
drivers/video/fbmem.c
drivers/video/fbmon.c
drivers/video/fbcmap.c
drivers/video/fbsysfs.c
drivers/video/modedb.c
drivers/video/fbcvt.c
drivers/video/display-sysfs.c

+ низкоуровневый драйвер видеокарты: либо vesa/uvesa, либо rivafb, либо nvidia.

Мимо

Учи матчасть

Очень содержательно )

Если чего надумаешь, пиши, завтра я прочитаю.

Подсказка — подумай, кто там прерывания разводит. Не Святой дух же в самом деле.

Мальчик, ты слил. nv отлично работает с ядром БЕЗ FB-подсистемы.

Учи уроки:)

андроид это не линух

>с переносом между машинами большие проблемы будут

В чем именно будут проблемы? По сути предлагается использовать видеокарту как сопроцессор. До сих пор с поддержкой сопроцессоров проблем в ядре вроде не было.

> Танненбаум просрал спор. Его Minix юзает два с половиной человека. А линукс...

Конечно же миллионы мух не могут ошибаться…

А виндовс вообще сколько юзает народу. Вывод — винда лучше?

>nv отлично работает с ядром БЕЗ FB-подсистемы

Мой тебе совет. Вместо того, чтобы исходить говном, лучше посмотри на исходники драйвера nv. Достаточно посмотреть хотя бы функцию инициализации. Из-за того, что ты пишешь некоторые слова с большой буквы, в целом это никак не влияет на правдивость фразы.

Учи уроки, девочка :) И смотри исходники

> к сожалению, чем выше уровень интерфейса подсистемы, тем он сложнее

В целом согласен, только это никогда никого не останавливало.

Все эти акселераторы оттого и вымерли, что сложные, дорогие и глючные

Предположу, что основная причина - тогда не было технических возможностей создать действительно сложный и функциональный аксельратор, хотя была необходимость. А сейчас есть возможность, но необходимость как-то утончилась (раньше IDE и близко не стоял к SCSI по функционалу и быстродействию, а теперь как-то и и не так, тогда дисковая подсистема очень сильно нагружала ЦП и брала очень много оперативной памяти, а сейчас вроде и нет).

Даже в простейшем файловом акселераторе непонятно, как включать

новые файловые системы, дефрагментацию и восстановление данных, ресайз и другие служебные вещи, mmap и т.д.

Файловые системы, дафрагментация, восстановление данных и т.д. можно включать примерно так, как игры загружают шредерные программы в видеокарту, только на уровне бута и ядра. mmap в любом случае отобразится в чтение/запись каких-то блоков (если это не просто разделяемая память между процессами). Это все технические проблем, их можно решить, только необхожимость такого решения сейчас очень неочевидна. Также как в свое время была неочевидны выгоды 3Dfx.

А вообще я говорил не про то, что перенесение частей ядра в специализированные аксельраторы необходимо (особенно на домашнем компьютере), а то, что это, вообще говоря, не идиотская идея.

>андроид это не линух

4.2

Вы еще скажите, что бубунта - это линукс =)

Непонятной полезности фича. Что они собираются делать с латентностью GPU? ГПУ хорош, когда надо перелопатить большой кусок данных, по маленьким задачам его гонять невыгодно. Много таких задач в ядре? Могу вспомнить разве что шифрование, но оно и так прекрасно оффлоадится на аппаратные ускорители, гораздо лучше чем GPU (по латентности, скорости, энергопотреблению).

Само микроядро отсутствует.

>Все эти акселераторы оттого и вымерли, что сложные, дорогие и глючные

Амижники с тобой определенно несогласны.

>В целом согласен, только это никогда никого не останавливало.

Остановило. Софт-раид в итоге убил аппаратные раиды.

Предположу, что основная причина - тогда не было технических возможностей создать действительно сложный и функциональный аксельратор, хотя была необходимость.

еще десяток лет назад раид-контроллеры были. Акселерированные по самые гланды.

раньше IDE и близко не стоял к SCSI по функционалу и быстродействию, а теперь как-то и и не так

ну здесь другие причины. scsi как был самым быстрым, так им и остался. Но проиграл за счет несовместимостей, сложности и цены.

Файловые системы, дафрагментация, восстановление данных и т.д. можно включать

Ага. и кто это будет делать? Для ЦПУ все это пишет создатель ФС. А для тысячи и одного акселератора кто будет реимплементировать?

А потом придет китайец и сделает комп без акселераторов на тысячу юаней дешевле и пинцет твоему идеальному пецуку. Собственно, сам писи представляет собой продукт ценовой войны. Проще, дешевле, массовей.

Также как в свое время была неочевидны выгоды 3Dfx.

очевидны. без 3dfx был 1 fps, а с ним - 30-50. Новые игры, новые возможности. За это будут платить.

А вообще я говорил не про то, что перенесение частей ядра в специализированные аксельраторы необходимо (особенно на домашнем компьютере), а то, что это, вообще говоря, не идиотская идея.

В большинстве случаев - идея бесполезная просто потому что слишком дорого, а в итоге нефункционально и ненадежно. Есть конкретные задачи - декодирование аудио/видео потока, акселерация графики, расчетные алгоритмы, то есть четкие локальные задачи, реализация которых сулит большие выгоды. А все остальное никогда не окупится.

>Амижники с тобой определенно несогласны.

сравни объемы продаж cpu и любого акселератора за исключением видеокарт.

Оффлоад-механизмы в SOHO-роутерах, разнообразные декодеры в плеерах и телефонах, ускорители шифрования (теперь уже и в процессорах), и прочая эмбеддовка. Все это вместе составляет сильно большую долю, чем видеокарты, и даже чем десктоп-процессоры.

Ах да, еще имидж- и видеопроцессинг забыл в фото-видеодевайсах. Камера только на обычном процессоре - нонсенс. Ну и вообще еще много чего.