В серверах Sun появится система виртуализации

>> Очевидно, что если вытащить последние две инструкции, выполняющиеся при переключении контекста, то ими окажется обновление tss

>Только снятие Busy flag с дескриптора (LDT || GDT) TSS. Это является необходимым и достаточным.

>>(хотя это даже не предпоследняя) и jump.

>в смыле ljmp на селектор.

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

>Да туда можно понаписать очень много всего, но снятие Busy flag и ljmp являются необходимыми и достаточными условиямми для выполнения переключения.

??? Т.е. в cr* писать не нужно, а в tss обновлять только флаги? И как же произойдет user->kernel переключение контекста в этом случае? Ааа, наверное кто-то за нас возьмет, например, указатель ядерного стека и перепишет сегментные регистры?

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

>xnix * (30.01.2006 17:51:49)

>Т.е. в cr* писать не нужно

не нужно.


Сюда попадаем по таймеру
extern timer_call
timer_s:
    pusha
    push ds
    push es
    push fs
    push gs

    mov ax, 0x10
    mov ds, ax
    mov es, ax
    mov fs, ax
    mov gs, ax
    mov eax, esp

    push eax
    mov eax, timer_call
     ;вызываем сишну функцию
    call eax
    pop eax

    pop gs
    pop fs
    pop es
    pop ds
    popa
    add esp, 8
    iret

void timer_call(struct regs *rr){
//Скажем, что прерывание завершилось.
outportb(0x20, 0x20);
schedule();
}

void schedule(){
....

//код выбора процессов из очереди не приводил, вот переключение
sw2(tasks[c_proc].selector);
....
}

void sw2(unsigned int selector)
{
   unsigned int sel[2];
   sel[1] = selector;
extern void tss_no_busy( int selector);
tss_no_busy(selector);
   asm ("ljmp %0": :"m" (*sel));//Прыгаем на селектор следующей задачи
}

void tss_no_busy(int selector){
int num_=selector/0x8;
gdt[(num_*2)+1]=gdt_s[(num_-6)];
//gdt - таблица дескрипторов , gdt_s -- ее копия (там busy flag не стоит)
}

>а в tss обновлять только флаги?

Не в TSS,а в его дескрипторе в  GDT||LDT!!

Скажите честно, это эмуляция многозадачности в DOS или аналогичной ОС? Я серьезно, это _НЕ_ многозадачность.

Здесь нет ни tlb, ни работы между несколькими кольцами.

И даже в вашем коде делается сохранение регистров (что вполне очевидно).

>Здесь нет ни tlb

Не написал еще ):

>ни работы между несколькими кольцами.

Это есть, проги работают на R3 , есть и VM8086.

>Скажите честно, это эмуляция многозадачности в DOS или аналогичной ОС?

Нет

>Я серьезно, это _НЕ_ многозадачность.

Еще скажи что это не может работать :)

Пояснение еще раэ: это _hardware_ task switching, это НЕ STACK SWAPPING(в Linux ядре)!

>>Здесь нет ни tlb

>Не написал еще ):

Там будет загрузка сегментов в cr*.

>>ни работы между несколькими кольцами.

>Это есть, проги работают на R3 , есть и VM8086.

А куда сохраняется стек r0 при переключении в r3?

>>Скажите честно, это эмуляция многозадачности в DOS или аналогичной ОС?

>Нет

А очень похоже.

>>Я серьезно, это _НЕ_ многозадачность.

>Еще скажи что это не может работать :-)

Есть такое мнение :) Шутка.

>Пояснение еще раэ: это _hardware_ task switching, это НЕ STACK SWAPPING(в Linux ядре)!

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

>xnix * (30.01.2006 19:15:45)

>А куда сохраняется стек r0 при переключении в r3?

В TSS ядра.

>Это очень малая часть того, что выполняется при переключении контекста. Если это работает в вашей системе, то это еще не означает, что это действительно переключение контекста, как бы это не называлось.

Да,не спорю, но это необходимо и достаточно .Кстати там еще должно быть сохранение состояния мат. сопроцессора, тоже еще не написал :(

>действительно переключение контекста, как бы это не называлось.

Существует несколько способов осущесвления мултизадачности.hw tswitching появился со времен 386 и дальше не развивался.Сейчас его редко используют, так как он значительно проигрывает по скорости software task switching(stack swapping -- один из вариантов).Кратко о hw : в нем все делает проессор(+), инициализировать очень сложно(-), работает медленнее(-). Несмотря на то , что объем кода, отвечающий за переключение мал, работает это медленне.

Исходя из всего этого, я рискну предположить, что в Sun T1 с поддержкой hw task switching они получать скорее падение производительности и неудобства.

>Исходя из всего этого, я рискну предположить, что в Sun T1 с поддержкой hw task switching они получать скорее падение производительности и неудобства.

А то архитектуры разные - это никого не волнует что-ли ?
Может они умудрились сделать это быстро

> неа, в x86* - полупрограммное, то есть переключится
> только когда скажешь.
Кто мешает task-gate в IDT запихнуть, и сделать
переключение полностью аппаратным? jump на TSS - лишь
частный случай.

> ??? Т.е. в cr* писать не нужно, а в tss обновлять
> только флаги? И как же произойдет user->kernel
> переключение контекста в этом случае? Ааа, наверное
> кто-то за нас возьмет, например, указатель ядерного
> стека и перепишет сегментные регистры?
Товарищ, почитайте же доки наконец. И хватит искать
здесь аналогии с тем, как это делается в linux, ибо
там это действительно делается ручками, но на то есть
причины (подробности легко найдёте в google).
Действительно, все регистры перепишутся сами, но
из TSS, а стек ядра тут вообще не при чём.
RTFM короче, по тому как достал ваш беспочвенный спор
на 2 страницы. :)

Подскажите по Sun T2000 - как я понял, там максимум что можно поставить -
это ОДИН 8-ядерный процессор Ниагара. Операционка увидит 8 логических процессоров.
Ну и соотвественно, по мощности эта машина может тягаться с машинами класса
SUnFire880. Это так и есть?
Вроде как даже в Вымпелкоме провели тестирование T2000 - он показал
на 30% лучшую производительность, нежели "обычный 8-процессорный сервер".
И главное - Sun планирует выпускать 4-процессорные сервера на базе Ниагары?

http://www.osp.ru/cw/2005/48/030_1.htm
**************
Перед выпуском на рынок Sun Microsystems провела мощную кампанию бета-тестирования, в которой участвовали более 100 крупных предприятий по всему миру, в том числе и в России. Например, в компанию «ВымпелКом» был поставлен T2000 с операционной системой Solaris 10, его сравнивали с восьмипроцессорным Sun Fire v880 на процессорах Ultra­SPARC III/900 МГц. Часть биллинговой системы, работающая под управлением BEA Weblogic и ОС Solaris 8, без какой-либо модификации была перенесена на новый сервер. Производительность T2000 оказалась на 30%-40% выше, что вызвало самые положительные эмоции у специалистов, которые осуществляли тестирование.
***********

>> ??? Т.е. в cr* писать не нужно, а в tss обновлять > только флаги? И как же произойдет user->kernel > переключение контекста в этом случае? Ааа, наверное > кто-то за нас возьмет, например, указатель ядерного > стека и перепишет сегментные регистры?

>Товарищ, почитайте же доки наконец. И хватит искать здесь аналогии с тем, как это делается в linux, ибо там это действительно делается ручками, но на то есть причины (подробности легко найдёте в google). Действительно, все регистры перепишутся сами, но из TSS, а стек ядра тут вообще не при чём. RTFM короче, по тому как достал ваш беспочвенный спор на 2 страницы. :-)

Мой юный друк, ничего само не сделается, посмотрите же наконец, как устроена любая архитектура - и даже в вышеобозначенном примере регистры сохраняются руками. С сегментами там не работают и TLB не используется, поэтому и нет модификаций cr*. Стек ядра здесь при том, что при переключении контекста r0->r3 он должен куда-то сохраняться, например в TSS. Но кто его туда сохранит, неужели снова сам?

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

anonymous (31.01.2006 8:21:49)

> бррр, а как 16 процов то получилось? psrinfo -v можно ?
> shkoda (*) (30.01.2006 16:34:42)

16 процов? Ну это говорит только о том, что Вы, к сожалению, даже не прочитали сановские статейки ... Про новый камушек...
psrinfo -v:
Status of virtual processor 0 as of: 01/31/2006 13:14:58
  on-line since 01/30/2006 16:50:17.
  The sparcv9 processor operates at 1000 MHz,
        and has a sparcv9 floating point processor.
Status of virtual processor 1 as of: 01/31/2006 13:14:58
  on-line since 01/30/2006 16:50:19.
...
Status of virtual processor 14 as of: 01/31/2006 13:14:58
  on-line since 01/30/2006 16:50:19.
  The sparcv9 processor operates at 1000 MHz,
        and has a sparcv9 floating point processor.
Status of virtual processor 15 as of: 01/31/2006 13:14:58
  on-line since 01/30/2006 16:50:19.
  The sparcv9 processor operates at 1000 MHz,
        and has a sparcv9 floating point processor.
Я полный вывод делать не буду, ладно ?
И так все ясно.
http://www.sun.com/processors/UltraSPARC-T1/
А вот это на почитать.

>Просто стУдент 5го курса решил видимо тут пощеголять, мол типа ай да я, ай да сцысадмин, >ибо кроме количества ядер ЦПУ у него и модель сервера Т200 тоже какая-то странная. >И что это еще за кртерий "работает очень хорошо". Это собственно как? >XCHG * (*) (30.01.2006 17:09:05)

Зависть задушила ? :) Не расстраивайся, я не студент, а про архитектуру процессора (sun4v) все же почитай, да зайди на солярке в каталог /usr/platform , может прекратишь трепаться без повода. Солярка-то хоть есть ? Или дать адресок, откуда НАХАЛЯВУ скачать?

> Производительность T2000 оказалась на 30%-40% выше, что вызвало самые положительные эмоции у специалистов, которые осуществляли тестирование.

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

> Зависть задушила ?

странная однако зависть
раньше подсолнухи не преминули бы попрекнуть х86 архитектурой, длинным конвейером и тд и тп - теперь когда очевидно что х86 переплюнула спарки по всем важным параметрам (достаточно взглянуть на сановский лоуэнд) то подсолнухи выбирают уже другие лозунги "даешь энергопотребление" "даешь количество ядер" и тд потому что цена/производительность они полностью просрали.

честно говоря приведенные параметры - 8 ядер 32 потока на 8 Гбайт памяти и пару сказюков у меня вызвало только подозрение в слабосильности Т1. спросите у кого нибудь 8way opteron с 8 гигами памяти и парой винтов - да вас просто на смех поднимут потому что конфигурация сильно разбалансирована.

Да ладно, я _честно_ не хочу впадать во флейм.

Камушек получился неординарный, свое место под солнцем он найдет. Эт точно.

Ну и в догонку - у этой железки "дырок" PCI-x/e достаточно, чтобы его легко можно было подключить к существующей SAN.

>Зависть задушила ? :) Не расстраивайся, я не студент, а про архитектуру процессора (sun4v) все же почитай,
>да зайди на солярке в каталог /usr/platform , может прекратишь трепаться без повода. Солярка-то хоть есть ?
>Или дать адресок, откуда НАХАЛЯВУ скачать?
Лучше дай адресок где написано что у этого Т1 16 виртуальных процессоров, а то на сун.ком упорно пишут
про 8 ядер по 4 потока. Или солярка может воспринимать это чудо как 8х4/16х2/32х1?
Для меня лично сан это пройденный этап, сейчас интересуюсь этим исключительно по инерции.


>Камушек получился неординарный, свое место под солнцем он найдет. Эт точно.
Да, действительно неординарный. 8 средненьких ядрышек слепленных в одну микросхему.
С не меньшим успехом можно было всадить туда 128 штук спарк v7.

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

> что вызвало самые положительные эмоции у специалистов,

?????

32-х поточный 8 процессорный Т1 оказался всего на 30-40% шустрее 8 процессорного спарка ? если учесть что Т1 - 1ГГц а сравнивали с 900МГцовыми спарками то выигрыш за счет новой архитектуры всего 20-30%. видать очень фиговые в Т1 потоки - 4 потока на 1 ядре еле уделывают 1 старенький спарк.

http://www.osp.ru/cw/2005/48/030_1_t1.htm

ой не могу :)))))
LOL

Sun T1000 поддерживает максимум 32 Мбайт памяти !!!

В вымпелкоме тесты проходили на java 1.3, которая не особо хорошо ложилась на большое кол-во хардварных тредов. 1.4-1.5 работают гораздо быстрее.

Тесты на старой яве проводились из-за ограниченности времени на тестирование.

>Лучше дай адресок где написано что у этого Т1 16 виртуальных процессоров, а то на сун.ком упорно пишут про 8 ядер по 4 потока. Или солярка может воспринимать это чудо как 8х4/16х2/32х1?

>Для меня лично сан это пройденный этап, сейчас интересуюсь этим исключительно по инерции.

Я рад - получается конструктивный разговор.

В действительности - эта машинка (именно эта) содержит 4 физ. ядра на пластине х 4 потоков исполнения. Сейчас, если я не ошибаюсь, доступны 6 и восьми ядерные T1 (http://catalog.sun.com). Соляра видит _16_ виртуальных процессоров (virtual processor). Я думаю, psrinfo действительно доказательно; (я не требую принимать на веру мои слова и выводы с консоли - может найдется кто еще, подвердит или опровергнет, сам ждал, пока смогу увидеть). Что лично у меня поначалу вызвало вопрос - а как же лицензировать - ведь 16 CPU - это ОГОГО какие бабки; по крайней мере с Oracle все ясно - это радует (http://blogs.sun.com/roller/page/drapeau?anchor=oracle_changes_pricing_strategy) :)

http://opensparc.sunsource.net/nonav/index.html - ну а это - для затравки :) Интел такого еще не отдавал.

Я не пытаюсь ПИАРИТЬ Sun или T1 конкретно. Я просто делюсь своей радостью :) , и надеюсь , что кто-то еще ПО ДОСТОИНСТВУ оценит этот камушек/машинку в целом.

> посмотрите же наконец, как устроена любая
> архитектура
Разговор идёт об x86, не виляйте.

> С сегментами там не работают и TLB не используется,
> поэтому и нет модификаций cr*.
cr3 переписывается из TSS автоматом, все сегментные
регистры тоже (да и чем они лучше других?) - чего
вам не хватает то? Это - полная смена контекста.
Если надо всякие там dr* регистры переписывать, или
ещё какую экзотику - это, наверное, уже ручками, но
это почти никогда не требуется.

> Стек ядра здесь при том, что при переключении
> контекста r0->r3 он должен куда-то сохраняться,
> например в TSS. Но кто его туда сохранит, неужели
> снова сам?
Это глупости. Тут вы явно уже даже исходники linux
просмотреть не удосужились.
При переключении r0->r3 сохранять контекст ядра не
нужно. В эту точку возвращаться не придётся. В
ядро вы снова попадёте либо по системному вызову,
либо по прерыванию/исключению. Точки входа
фиксированы. При переключении r0->r3 контекст ядра
не сохраняется. RTFM, опять же.

Ну и к вопросу о PR-ре - вот такие фотки зацепил в англии :) http://genernext.nest.org.ru/v/TRAVEL/Basinstoke-London-Quantum/London-UK-T1-PR/

Наши пока на "шашечки" такую рекламу не расклеивают. А жаль - вместо макарон и др. гуана приятно видеть такие вещи.

>> С сегментами там не работают и TLB не используется, > поэтому и нет модификаций cr*. >cr3 переписывается из TSS автоматом, все сегментные регистры тоже (да и чем они лучше других?) - чего вам не хватает то? Это - полная смена контекста. Если надо всякие там dr* регистры переписывать, или ещё какую экзотику - это, наверное, уже ручками, но это почти никогда не требуется.

Каким автоматом? Преобразования адреса через TLB автоматом происходит? Адрес страниц в cr3 пишется автоматом?

FPU опять же кто будет сохранять?

В GDT TLS данные о новом процессе пишутся руками. FS/GS загружаются руками.

c4 обновляется руками регулярно при переключении контекста, но не на всех i386 процессорах.

А если userspace поддерживает сигналы, чего нет в предыдущем примере, то добавляется еще немало

>> Стек ядра здесь при том, что при переключении > контекста r0->r3 он должен куда-то сохраняться, > например в TSS. Но кто его туда сохранит, неужели > снова сам? >Это глупости. Тут вы явно уже даже исходники linux просмотреть не удосужились. При переключении r0->r3 сохранять контекст ядра не нужно. В эту точку возвращаться не придётся. В ядро вы снова попадёте либо по системному вызову, либо по прерыванию/исключению. Точки входа фиксированы. При переключении r0->r3 контекст ядра не сохраняется. RTFM, опять же.

Разговор окончен. Вы либо не понимаете о чем говорите, либо не понимаете о чем речь шла выше, ибо слова ваши верны, но они совершенно не в теме.

Ядерный стек при r3->r0 берется из tss процесса, куда он был сохранен ранее, и отнюдь не самостоятельно.

> anonymous (31.01.2006 21:46:21)

> RTFM короче, по тому как достал ваш беспочвенный спор на 2 страницы. :)

Мне интересно, пусть спорят.

> Адрес страниц в cr3 пишется автоматом?
Да. Посмотрите, к примеру, linux/arch/i386/kernel/doublefault.c,
и спросите себя, для чего там инициализируется __cr3
в doublefault_tss.

> FPU опять же кто будет сохранять?
Это другое дело. Знаю на счёт FPU, но в простейшем
случае его можно не использовать. К тому же это всего
одна команда: fsave/frstor, так что это не сильно ломает
концепцию аппаратного переключения.

> В GDT TLS данные о новом процессе пишутся руками.
Это здесь вообще не причём. То, что вы видите это
в linux, ничего не значит. Поищите это в 2.4 ядрах,
или 2.2. И вообще к теме не относится - OS-specific
feature.

> FS/GS загружаются руками.
Я не знаю, как с вами спорить. Вы смотрите в исходник
ядра, но нифига там не понимаете. Вам уже сказали, что
там используется *софтовое* переключение, именно
по этому *там* оно ручками. А так бы автоматом
загружалось. http://www.online.ee/~andre/i80386/Chap7.html
Цитаты не буду даже приводить, сами найдёте что нужно.

> А если userspace поддерживает сигналы, чего нет в
> предыдущем примере, то добавляется еще немало
Не надо про специфичные для ОС вещи. Разумеется
для операционки понятие контекста процесса шире,
чем для CPU. CPU способен сменить только ту часть
контекста, которая относится к нему. Всё, что к
этому добавляет ОС, она должна переключать сама.
Это как бы очевидно, про это речь не идёт.

> Ядерный стек при r3->r0 берется из tss процесса,
> куда он был сохранен ранее, и отнюдь не
> самостоятельно.
Это ложь. Либо подтвердите ссылкой на исходник/URL,
либо отдохните. В tss записан только esp0, он
указывает, какое значение примет esp при переключении
r3->r0. Но вот то, что будет в стеке - этого в TSS нет.
При переключении r3->r0 в стек ядра кладётся только
стандартный кадр возврата, больше там ничего нет
(про sysenter говорить не будем, я про стандартный
interrupt gate).

> либо отдохните. В tss записан только esp0, он
Хотя предполагаю, что вы опять же увидели в ядре
что-то типа tss->esp0 = thread->esp0, и притащили это
сюда, как и всё остальное. Тогда это безсмыслено.
Так можно продолжать до бесконечности - вы будете
тащить из ядра код совтового переключения, а я
буду утверждать, что это можно сделать и аппаратно.
Прочитать доки на проц, а так же понять, что то, что
делает ядро linux, тут совершенно не причём, вы не
удосуживаетесь. Смысла спорить не вижу.
Вы только поймите одно: linux не переключает TSS!
У него используется только *один* TSS! (если быть
более точным, то по одному TSS на каждый *процессор*,
но не на каждый *процесс*). Именно по этому то, что
вы там наковыряли в ядре, к спору об аппаратном
переключении контекста вообще не относится. Не
тратьте время впустую, прочтите умную книгу, если
ядро вам не по зубам.

> Вы либо не понимаете о чем говорите, либо не
> понимаете о чем речь шла выше, ибо слова ваши верны,
> но они совершенно не в теме.
> Ядерный стек при r3->r0 берется из tss процесса, куда
> он был сохранен ранее, и отнюдь не самостоятельно.
Мля, вы наверное хотели сказать "указатель стека",
а не "стек"? И меня ещё обвиняете, что я не по теме
высказываюсь, решив, что вы про сохранение контекста
в стеке говорите, а не про сохранение указателя?
Если эта догадка верна, то, пожалуй, дальнейший спор
и правда смысла не имеет. Я не знал, что вы базовых
понятий не знаете... Если же не верна, то поясните,
что же за "сохранение стека r0 в tss" вы имели ввиду.

>> Вы либо не понимаете о чем говорите, либо не > понимаете о чем речь шла выше, ибо слова ваши верны, > но они совершенно не в теме. > Ядерный стек при r3->r0 берется из tss процесса, куда > он был сохранен ранее, и отнюдь не самостоятельно. >Мля, вы наверное хотели сказать "указатель стека", а не "стек"? И меня ещё обвиняете, что я не по теме высказываюсь, решив, что вы про сохранение контекста в стеке говорите, а не про сохранение указателя?

И сколько же содержимого стека поместится 236 байт tss? Естественно указатель.

>Если эта догадка верна, то, пожалуй, дальнейший спор и правда смысла не имеет. Я не знал, что вы базовых понятий не знаете... Если же не верна, то поясните, что же за "сохранение стека r0 в tss" вы имели ввиду.

Спор подошел к ожидаемому финалу.

Резюме: знатоки аппаратного переключения контекста утверждали, что всего лишь несколько магических манипуляций с дескриптором GDT/LDT приведут к переключению контекста. Да, я с этим полностью согласен. Но дело в том, что для работы многозадачной ОС этого недостаточно, что и было приведено в примере аппаратного переключения контекста, и на что неоднократно указывалось выше: при любом переключении, будь то аппаратное, софтверное или какое-нибудь еще, _ВСЕГДА_ необходимо руками прописывать/сохранять некоторые параметры.

> И сколько же содержимого стека поместится 236 байт
> tss?
Это писец просто. Я вам ещё раз говорю, задолбали
смотреть в ядро linux и нифига там не понимать!
Кто вам сказал, что размер TSS ограничен 236 байтами?
Ясное дело, глянули в ядро... нда, смотришь в книгу,
видишь фигу - это точно про вас... Мои уговоры на
счёт RTFM явно результата не дают. Жаль. С таким
упорством далеко пойдёте.


> Естественно указатель.
Великолепно. До следующего спора научитесь излагать
свои мысли внятно, и не подменять базовые понятия,
когда они по отношению к предмету дискуссии являются
решающими.

> при любом переключении, будь то аппаратное,
> софтверное или какое-нибудь еще, _ВСЕГДА_
> необходимо руками прописывать/сохранять некоторые
> параметры.
Враньё. Это нужно далеко не всегда. Всё, что нужно
переключать руками, в разной степени опционально.
Самое важное - это конечно FPU. Сейчас говорить, что
FPU - optional, не серьёзно. Однако вспомните, что
были 386 процы без FPU (может даже и 486 были), и
на них тоже работал linux. И можно было даже работать
без ядрёной эмуляции FPU, если все проги собраны с
-msoft-float. Так что, скрепя сердцем, скажем, что
переключение FPU опционально. А дальше - всё.
TLS дескриптор - вообще фигня, сто лет без неё жили.
А что ещё? Да вроде бы и нет больше ничего. Или как?
И так получаем, что аппаратного переключения вполне
достаточно для вполне серьёзной работы. Ну а такому
продвинутому ядру, как linux-2.6, понадобилось
всего несколько, совсем не много дополнительных
возможностей - это ни о чём не говорит.

> Спор подошел к ожидаемому финалу.
Да, и этот финал - выявление вашей полнейшей
некомпетентности в обсуждаемом вопросе. Я долго
терпел всякие ваши cr3, fs/gs и тд, но последний
ваш перл о размере TSS окончательно меня добил,
и это уже не оставляет за вами возможности оправдаться.
RTFM вам не поможет.
"Это не диагноз, это уже приговор." (с)

>> Спор подошел к ожидаемому финалу.

>Да, и этот финал - выявление вашей полнейшей некомпетентности в обсуждаемом вопросе. Я долго терпел всякие ваши cr3, fs/gs и тд, но последний ваш перл о размере TSS окончательно меня добил, и это уже не оставляет за вами возможности оправдаться. RTFM вам не поможет. "Это не диагноз, это уже приговор." (с)

Минимальный размер tss - 104 байт (столько использует сам процессор), Linux использует 236.

О чем вы там говорили? Один tss на процессор? Читаем: http://www.embedded.com/showArticle.jhtml?articleID=55301875

Цитата: You can call this a state frame, a task image, context store, or whatever you like but in x86-land, it's called a task state segment (TSS). TSSes correlate to tasks one-to-one. As an x86 programmer, you get to create one TSS for every task, whether you've got just two tasks or the processor's theoretical limit of 8,096 tasks.

Кстати да, fs/gs тоже сохраняются процессором, я почему-то думал, что эти регистры прописываются руками.

Остальное все остается в силе. Не нужно громко кричать, пряча за этим собственную некомпетентность. Перечитайте еще раз, что я написал о сохранении руками при переключении контекста.

> О чем вы там говорили? Один tss на процессор? Читаем:
Да что же это такое, товарищ, вы издеваетесь? Что
я говорил?
---
Вы только поймите одно: linux не переключает TSS!
У него используется только *один* TSS! (если быть
более точным, то по одному TSS на каждый *процессор*,
но не на каждый *процесс*). Именно по этому то, что
вы там наковыряли в ядре, к спору об аппаратном
переключении контекста вообще не относится.
---
Вот точная цитата того, что я говорил. Надо ли
повторять, что тут идёт речь о том, как это сделано
в linux, а не как это вообще может быть сделано?
А вы мне даёте ссылку на описание проца - накуя?
Да, linux использует по одному TSS на проц, и именно
по этому там не используется аппаратное переключение.
И я подозреваю, что это не невнимательность ваша,
а опять таки незнание вопроса приводит к таким вот
"недоразумениям", которыми ваши сообщения изобилуют.

> Кстати да, fs/gs тоже сохраняются процессором, я
> почему-то думал, что эти регистры прописываются
> руками.
Вам подсказать почему, или не стоит в сотый раз
повторять? СмОтрите в ядро и ничего не понимаете,
вот почему.

> Не нужно громко кричать, пряча за этим собственную
> некомпетентность.
Вы мне конкретно покажите, где я сказал что-то не
так, ошибся, наврал и тд. Даже отвлекаясь от темы
спора, ваши сообщения просто изобилуют неточностями
и некомпетентностью. А мои? Может быть, но *вы* пока
ни на какие огрехи не указали. (точнее указали, и
ни раз, но это был бред)

> Минимальный размер tss - 104 байт (столько использует
> сам процессор), Linux использует 236.
Кстати говоря, опять же, наглая ложь! Нет, ну я
просто поражаюсь...
Ядро 2.6.12:
---
$ gdb vmlinux
(gdb) p sizeof(struct tss_struct)
$1 = 8704
(gdb)
---

Т.е. занимает он более 8К! Да там один только IO bitmap
8К занимает. Одним словом, я уже даже не знаю, как
всё это назвать. Не нравятся мне местные выражения
типа "газификация луж", но просто еле сдерживаюсь...

>> Минимальный размер tss - 104 байт (столько использует > сам процессор), Linux использует 236. >Кстати говоря, опять же, наглая ложь! Нет, ну я просто поражаюсь... Ядро 2.6.12: --- $ gdb vmlinux (gdb) p sizeof(struct tss_struct) $1 = 8704 (gdb) ---

>Т.е. занимает он более 8К! Да там один только IO bitmap 8К занимает. Одним словом, я уже даже не знаю, как всё это назвать. Не нравятся мне местные выражения типа "газификация луж", но просто еле сдерживаюсь...

2.4 - tss: 256 байт за вычетом 5*sizeof(unsigned long) неиспользуемого паддинга получаем 236 байт.

Впрочем, такая неадекватная реакция говорит о компетентности автора.

>> Не нужно громко кричать, пряча за этим собственную > некомпетентность.

>Вы мне конкретно покажите, где я сказал что-то не так, ошибся, наврал и тд. Даже отвлекаясь от темы спора, ваши сообщения просто изобилуют неточностями и некомпетентностью. А мои? Может быть, но *вы* пока ни на какие огрехи не указали. (точнее указали, и ни раз, но это был бред)

Я просто приведу цитату, т.к. кричать в стену бесполезно: "Перечитайте еще раз, что я написал о сохранении руками при переключении контекста."

> Впрочем, такая неадекватная реакция говорит о
> компетентности автора.
Какая ещё реакция? Вы сказали
---
И сколько же содержимого стека поместится 236 байт
tss?
---
когда речь о linux вообще не шла, тем более о 2.4.
А в 8К уже можно что угодно положить, даже стек ядра.
А то, что в старых ядрах был маленький IO bitmap, это
я как бы и без вас знаю, man ioperm читал когда вы ещё
под стол пешком ходили.:) Давайте ещё ловить меня на
том, что в _очень_ старых ядрах linux было использовано
аппаратное переключение, и по этому всё, что я говорю,
не верно...
Неадекватная реакция - она на то, что люди спорят о
вещах, которых не понимают. Вот и всё.

> Я просто приведу цитату, т.к. кричать в стену
> бесполезно: "Перечитайте еще раз, что я написал о
> сохранении руками при переключении контекста."
Да, бесполезно. Я устал от вашей некомпетенции, и
перечитывать весь этот бред заново, вдумываясь
в то, что вы там имели ввиду (особенно после того,
как вы стали подменять базовые понятия), мне уже не
охота. Ваши перлы не оставляют вам возможности
оправдаться, вне зависимости от того, где и когда
я вас недопонял (если и недопонял - скорее всего
ваша вина, за примерами далеко ходить не надо).
На этом всё. Может ещё свидимся.