as / scheduler question
Nick
With the sheduler work Ingo and I have been doing I was wondering if there was possibly a problem with requeuing kernel threads at certain intervals? Ingo's current version requeues all threads at 25ms and I just wondered if this number might be a multiple or factor of a magic number in the AS workings, as we're seeing a few changes in behaviour with AS only. I'm planning on leaving kernel threads out of this requeuing, but I thought I could also pick your brain.
Con
Quoted 11 lines · Con Kolivas
Nick
With the sheduler work Ingo and I have been doing I was wondering if there was possibly a problem with requeuing kernel threads at certain intervals? Ingo's current version requeues all threads at 25ms and I just wondered if this number might be a multiple or factor of a magic number in the AS workings, as we're seeing a few changes in behaviour with AS only. I'm planning on leaving kernel threads out of this requeuing, but I thought I could also pick your brain.
What does "requeues all threads at 25ms" mean?
The only dependency we should have there is that kblockd should be scheduled promptly after it is woken. It is reniced by -10 so it should be OK. Renicing it further or making it SCHED_RR/FIFO would be interesting.
Quoted 11 lines · Andrew Morton
Quoted 9 lines · Con Kolivas
Nick
With the sheduler work Ingo and I have been doing I was wondering if there was possibly a problem with requeuing kernel threads at certain intervals? Ingo's current version requeues all threads at 25ms and I just wondered if this number might be a multiple or factor of a magic number in the AS workings, as we're seeing a few changes in behaviour with AS only. I'm planning on leaving kernel threads out of this requeuing, but I thought I could also pick your brain.
Quoted 5 lines
What does "requeues all threads at 25ms" mean?
The only dependency we should have there is that kblockd should be scheduled promptly after it is woken. It is reniced by -10 so it should be OK. Renicing it further or making it SCHED_RR/FIFO would be interesting.
Ingo introduced the concept of TIMESLICE_GRANULARITY a while ago. All processes currently running on the active queue get interrupted in their timeslice after TIMESLICE_GRANULARITY (currently set at 25ms and the subject of another thread), and put on the tail of the active array to continue their timeslice after other processes at the same priority on the active queue get to run, also for at most TIMESLICE_GRANULARITY. If kblockd is reniced to -10 it wont have a problem unless something else ends up with the same dynamic priority which would only happen if there are interactive tasks reniced to -10. If it's the only process on the active array at that priority it _should_ run unaffected.
Con
Quoted 4 lines · Con Kolivas
If kblockd is reniced to -10 it wont have a problem unless something else ends up with the same dynamic priority which would only happen if there are interactive tasks reniced to -10. If it's the only process on the active array at that priority it _should_ run unaffected.
Even if it is not, it should easily complete what little it has to do within 25ms... so Ingo's patches should not affect it.
Robert Love
Quoted 16 lines · Con Kolivas
Quoted 14 lines · Andrew Morton
Quoted 10 lines · Con Kolivas
Nick
With the sheduler work Ingo and I have been doing I was wondering if there was possibly a problem with requeuing kernel threads at certain intervals? Ingo's current version requeues all threads at 25ms and I just wondered if this number might be a multiple or factor of a magic number in the AS workings, as we're seeing a few changes in behaviour with AS only. I'm planning on leaving kernel threads out of this requeuing, but I thought I could also pick your brain.
What does "requeues all threads at 25ms" mean?
Quoted 9 lines
Quoted 4 lines
The only dependency we should have there is that kblockd should be scheduled promptly after it is woken. It is reniced by -10 so it should be OK. Renicing it further or making it SCHED_RR/FIFO would be interesting.
Ingo introduced the concept of
TIMESLICE_GRANULARITYa while ago. All processes currently running on the active queue get interrupted in their timeslice afterTIMESLICE_GRANULARITY(currently set at 25ms and the subject of another thread), and put on the tail of the active array to continue their timeslice after other processes at the same priority on the active queue get to run, also for at mostTIMESLICE_GRANULARITY. If kblockd is reniced to -10 it wont have a problem unless something else ends up with the same dynamic priority which would only happen if there are interactive tasks reniced to -10. If it's the only process on the active array at that priority it
_should_ run unaffected.
OK, well if they've been running for more than 6ms then AS goes out of the picture, so no, shouldn't make a difference.
In general, on the read side, the disk scheduler can determine how tasks get woken after waiting on reads, and on the write side its more the request allocation. If CPU bound processes are running as well though, then its a process scheduler decision about how soon a woken process gets to run - I think IO performance wants this figure to be nice and low.
Quoted 16 lines · Con Kolivas
Quoted 14 lines · Andrew Morton
Quoted 10 lines · Con Kolivas
Nick
With the sheduler work Ingo and I have been doing I was wondering if there was possibly a problem with requeuing kernel threads at certain intervals? Ingo's current version requeues all threads at 25ms and I just wondered if this number might be a multiple or factor of a magic number in the AS workings, as we're seeing a few changes in behaviour with AS only. I'm planning on leaving kernel threads out of this requeuing, but I thought I could also pick your brain.
What does "requeues all threads at 25ms" mean?
Quoted 9 lines
Quoted 4 lines
The only dependency we should have there is that kblockd should be scheduled promptly after it is woken. It is reniced by -10 so it should be OK. Renicing it further or making it SCHED_RR/FIFO would be interesting.
Ingo introduced the concept of
TIMESLICE_GRANULARITYa while ago. All processes currently running on the active queue get interrupted in their timeslice afterTIMESLICE_GRANULARITY(currently set at 25ms and the subject of another thread), and put on the tail of the active array to continue their timeslice after other processes at the same priority on the active queue get to run, also for at mostTIMESLICE_GRANULARITY. If kblockd is reniced to -10 it wont have a problem unless something else ends up with the same dynamic priority which would only happen if there are interactive tasks reniced to -10. If it's the only process on the active array at that priority it
_should_ run unaffected.
OK, well if they've been running for more than 6ms then AS goes out of the picture, so no, shouldn't make a difference.
In general, on the read side, the disk scheduler can determine how tasks get woken after waiting on reads, and on the write side its more the request allocation. If CPU bound processes are running as well though, then its a process scheduler decision about how soon a woken process gets to run - I think IO performance wants this figure to be nice and low.
Quoted 1 line · Andrew Morton
What does "requeues all threads at 25ms" mean?
I think he is talking about the timeslice granularity Ingo readded in his latest patch (TIMESLICE_GRANULARITY, which is 25ms with HZ=1000). Every 25ms the currently running task is preempted if there is another runnable task at its current priority. I.e., tasks at the same priority are round-robined every 25ms, until there timeslices expire.
Quoted 3 lines
The only dependency we should have there is that kblockd should be scheduled promptly after it is woken. It is reniced by -10 so it should be OK. Renicing it further or making it SCHED_RR/FIFO would be interesting.
Yep, and I don't think Ingo's patch would effect this.
Robert Love