Мммм не, принципно timeslice-a е 10 милисекунди - във всички x86_64 и всички ia32 ядра от няколко версии насам, за алфите и powerpc-тата продължава да е 100мс (за последното не съм 100% сигурен, може и тях да са ги минали на HZ=1000), а за разни изкривени embedded архитектури слагат дори по-нисък timeslice.
Въпросът е друг. Значи в момента в който нишките са станали нещо модерно, хората тръгнали да мислят по въпроса как да си реализират нишките. Та значи има 2 варианта това да стане - по-простият е 1:1 модела, по-сложният е m:n модела. И всички първоначално (включително линукс) са избрали по-сложният вариант.
1:1/m:n е просто съотношение на task scheduler entries към threads. В първият вариант всяка нишка е task scheduling entry - и може да се стартира по всяко време на всяко ядро. Вторият вариант е по-различен: нишките се разглеждат като подмножество на процеса и на един процесор може да се изпълнява само един процес (съответно някоя от тези n нишки). Но това означава че във всяко едно време нишките, създадени от един процес могат да вървят само на процесорът, на който върви процеса.
Сега изглежда много малоумно, че хората масово са избирали m:n модела (включително линукс с linuxthreads в 2.4 времената).
Това е оправдано обаче заради цената на context switching-a. Значи всичките нишки в рамките на един процес си споделят общо виртуално адресно пространство. "Скъпото" нещо на task switching-a е че може да се наложи да "превключиш" между адресни пространства (ако превключваш между различни процеси или нишки от различни процеси). Когато това стане трябва да изчистиш процесорния кеш (наричан TLB cache) и всички следващи достъпвания до РАМ-та да стават бавно и през серия от page faults.
В 2.6 са работили (и още работят) по scheduling механизъм, който има предвид това и "предпочита" scheduling на процеси стига да не се налага TLB flushes по възможност, демек предпочита се ако е възможно да се превключва между нишки от един и същ процес, споделящи общо адресно пространство.
Разбира се това не винаги е възможно. За сметка на това, РАМ паметта става все по-бърза и по-бърза и поради тази причина, минаването към 1:1 threading механизма се е оказало едно много прозорливо и умно решение. Чак след това някои БСД системи почват да следват примера на линукс, което е доста показателно за някои работи
task struct, тези 200 мс за които говориш са нещо друго - това е друга дивотия на task scheduling-a, която се занимава с балансирането на smp nodes.