* Re: as / scheduler question
2003-07-28 23:25 ` Con Kolivas
@ 2003-07-28 23:32 ` Robert Love
2003-07-31 6:43 ` Nick Piggin
2003-07-31 6:45 ` Nick Piggin
2 siblings, 0 replies; 7+ messages in thread
From: Robert Love @ 2003-07-28 23:32 UTC (permalink / raw)
To: Con Kolivas; +Cc: Andrew Morton, piggin, linux-kernel
On Mon, 2003-07-28 at 16:25, Con Kolivas wrote:
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: as / scheduler question
2003-07-28 23:25 ` Con Kolivas
2003-07-28 23:32 ` Robert Love
@ 2003-07-31 6:43 ` Nick Piggin
2003-07-31 6:45 ` Nick Piggin
2 siblings, 0 replies; 7+ messages in thread
From: Nick Piggin @ 2003-07-31 6:43 UTC (permalink / raw)
To: Con Kolivas; +Cc: Andrew Morton, linux-kernel
Con Kolivas wrote:
>On Tue, 29 Jul 2003 09:01, Andrew Morton wrote:
>
>>Con Kolivas <kernel@kolivas.org> wrote:
>>
>>>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.
>>
>
>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.
>
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: as / scheduler question
2003-07-28 23:25 ` Con Kolivas
2003-07-28 23:32 ` Robert Love
2003-07-31 6:43 ` Nick Piggin
@ 2003-07-31 6:45 ` Nick Piggin
2 siblings, 0 replies; 7+ messages in thread
From: Nick Piggin @ 2003-07-31 6:45 UTC (permalink / raw)
To: Con Kolivas; +Cc: Andrew Morton, linux-kernel
Con Kolivas wrote:
>On Tue, 29 Jul 2003 09:01, Andrew Morton wrote:
>
>>Con Kolivas <kernel@kolivas.org> wrote:
>>
>>>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.
>>
>
>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.
>
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.
^ permalink raw reply [flat|nested] 7+ messages in thread