[lkml]   [2003]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] O16int for interactivity
    On Fri, 15 Aug 2003, Timothy Miller wrote:

    > Con Kolivas wrote:
    > > Preemption of tasks at the same level with twice as much timeslice has been
    > > dropped as this is not necessary with timeslice granularity (may improve
    > > performance of cpu intensive tasks).
    > Does this situation happen where two tasks at different nice levels have
    > dynamic priority adjustments which make them effectively have the same
    > priority?
    > > Preemption of user tasks is limited to those in the interactive range; cpu
    > > intensive non interactive tasks can run out their full timeslice (may also
    > > improve cpu intensive performance)
    > What can cause preemption of a task that has not used up its timeslice?
    > I assume a device interrupt could do this, but... there's a question I
    > asked earlier which I haven't read the answer to yet, so I'm going to guess:
    > A hardware timer interrupt happens at timeslice granularity. If the
    > interrupt occurs, but the timeslice is not expired, then NORMALLY, the
    > ISR would just return right back to the running task, but sometimes, it
    > might decided to end the time-slice early and run some other task.
    > Right?

    Never. However, since the time-slice is 'time', the very instant that
    the hardware interrupt executes it's "iret", the hardware-timer may
    interrupt and the CPU gets taken away from the task.

    Suppose that the preemption timer ticked at 1 HZ intervals. Suppose
    that an awful interrupt service routine (one that loops inside) took 1
    second to be serviced. What would happen if a task was 3/4 of a second
    into its time-slice and then a hardware interrupt occurred?

    The CPU would be taken away at 3/4 second, given to the bad ISR, then
    the CPU would not be returned until (1) the one-second execution time
    had occurred, and (2), all other higher priority tasks had gotten their
    time-slices. Each of those higher-priority tasks, could further get
    interrupted by the rogue ISR. The result may be that you get the CPU
    back next Tuesday.

    > So, what might cause the scheduler to decide to preempt a task which has
    > not used up its timeslice?

    The scheduler does not preempt a task until its time has expired.
    However time is a constantly-expiring thing so interrupts can
    eat up a processes' time.

    The usual way for a process (task) to lose it's allocated CPU time-
    slice is to perform some I/O. When waiting for I/O, the kernel may
    give the CPU to somebody else.

    If, the scheduler worked on task-CPU time, rather than hardware-clock
    "wall time", maybe it would be more "fair" during periods of high
    interrupt activity. However, since interrupts occur anytime, they
    tend to attack all competing processes equally, therefore becoming
    "fair" unless it's one task that's generating all that interrupt
    activity, like network I/O, or some kinds of screen-interactivity.

    Dick Johnson
    Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
    Note 96.31% of all statistics are fiction.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:47    [W:0.024 / U:24.012 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site