4

I've got some here and there chunks of information but no real, complete example of a real case, with a REAL time approximation(real as in human world;Ex:10^-7 sec/10^-5 sec or any order of magnitude).

To give some extra hints to what i want to know, i'll try an example and wait to be put on the right track:

3.2 and up version of linux kernel(you may need this to evaluate the scheduler)

~i5/i7 generation hardware(you may need this to approximate the main system clock)

take let's say 2 cases of "equal priority" number of processes 10^2 and 10^4(i know a lot of you may just go berzerk on me for that 10^4, but let's take this as an exercise)

if my question would be about a thread's time "of action", how would it translate? say you have a decent number of threads spread evenly between processes 10^2 processes each having ~10-100 threads vs only one busy process that has lots of threads ~10^4.

I assume the answer has lots of detailed tricky parts and some things are maybe missing from my question but just assume the common/average case if so,

Thank you.

user2485149
  • 91
  • 7

1 Answers1

5

Linux uses 100 milliseconds as the scheduler quantum, if that's what you were asking, in your own, convoluted way :-)

There's nothing saying a process has to use their entire quantum and, in fact, if they release early, I think their priority gets bumped up a bit as a reward.

paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
  • yes that is about it, i was assuming some serious calculus :) but what about the thread part? each process divides it equally to each of its threads? – user2485149 Jun 14 '13 at 08:39
  • 1
    @user2485149: Linux doesn't schedule processes, it schedules threads. There is no process concept in the scheduler itself, this is a smoke-and-mirrors operation now. See http://stackoverflow.com/questions/9305992/linux-threads-and-process/9306150#9306150 for more detail. – paxdiablo Jun 14 '13 at 08:48
  • 1 more thing tho, on a 2-core machine, 50-100 threads that overlap their quantum and get evacuated, produce up to 5 second delay for the 101-th thread, would not that be pretty bad? does not the quanta change with the number of threads? – user2485149 Jun 14 '13 at 09:15
  • @user2485149: yes, if you've got 100 _CPU-bound_ threads then something like that could happen. From memory, the 2.4 kernel averaged timeslices at about 200ms, 2.6 (where some big scheduling changes took place, although the later addition of the Completely Fair Scheduler was also important) improved that to 100ms but the problem can still arise if you double the load. Rarely have I seen _that_ many CPU-bound threads in my travels, though it is possible. – paxdiablo Jun 14 '13 at 12:17
  • must those threads be CPU-bound? does a context switch happens if they get hung on something like an accept() call, before 100ms have passed? i'm trying to figure out where is the trade-off between thread context switch and parallel accept() calls.. if that's a good idea to begin with. – user2485149 Jun 14 '13 at 12:28
  • @user2485149, if they're not CPU-bound, they won't use their entire quantum hence the impact on thread #101 won't be as bad. – paxdiablo Jun 14 '13 at 12:33
  • i'm not sure i understand why is that.. don't i/o threads(i personally care especially about accepting connections on multiple threads) get the same quanta? even if they just waste the CPU time? and isn't that more common than cpu-bound threads, at least in the server world? sorry to waste so much of your time but it seems you are one of the few sharing some nice insight. – user2485149 Jun 14 '13 at 12:49
  • @user2485149: I/O-bound threads don't spend their time on the runqueue, they tend to be hived off to another queue until whatever they're waiting for is ready. Hence, only CPU-bound threads tend to get scheduled a lot. – paxdiablo Jun 14 '13 at 13:17
  • right, i hope i got it now, they just context switch themselves off and only rejoin the runqueue when they are done waiting for any I/O signals. So to go back and answer my 1st question now: The average quanta used by I/O-bound threads is extremely small compared to the preemption quanta.And a final quiz :) : any idea where should i stop spawning threads as an order of magnitude, if i have very few CPU-bound jobs/threads and the only concern is thread context switch overhead slowing down too much the system. Thank you mate, anytime you need a hint about biking downhill, i'll be there :) – user2485149 Jun 14 '13 at 13:45