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
On Tue, 29 Jul 2003 09:01, Andrew Morton wrote:
> Con Kolivas <[email protected]> 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.
Con
Con Kolivas <[email protected]> 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.
On Mon, 2003-07-28 at 16:01, Andrew Morton wrote:
> 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.
> 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
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
Con Kolivas wrote:
>On Tue, 29 Jul 2003 09:01, Andrew Morton wrote:
>
>>Con Kolivas <[email protected]> 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.
Con Kolivas wrote:
>On Tue, 29 Jul 2003 09:01, Andrew Morton wrote:
>
>>Con Kolivas <[email protected]> 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.