Re: [PATCH] O13int for interactivity

From: Con Kolivas (kernel_at_kolivas.org)
Date: 08/05/03

  • Next message: Andrew Morton: "Re: [PATCH] O11int for interactivity" 
    Date:	Tue,  5 Aug 2003 15:16:08 +1000
To: Nick Piggin <piggin@cyberone.com.au>

    Quoting Nick Piggin <piggin@cyberone.com.au>:

    > Con Kolivas wrote:
    >
    > >Quoting Nick Piggin <piggin@cyberone.com.au>:
    > >
    > >
    > >>
    > >>Con Kolivas wrote:
    > >>
    > >>
    > >>>On Tue, 5 Aug 2003 12:21, Nick Piggin wrote:
    > >>>
    > >>>
    > >>>>No, this still special-cases the uninterruptible sleep. Why is this
    > >>>>needed? What is being worked around? There is probably a way to
    > >>>>attack the cause of the problem.
    > >>>>
    > >>>>
    > >>>Footnote: I was thinking of using this to also _elevate_ the dynamic
    > >>>
    > >>priority
    > >>
    > >>>of tasks waking from interruptible sleep as well which may help
    > throughput.
    > >>>
    > >>>
    > >>Con, an uninterruptible sleep is one which is not be woken by a signal,
    > >>an interruptible sleep is one which is. There is no other connotation.
    > >>What happens when read/write syscalls are changed to be interruptible?
    > >>I'm not saying this will happen... but come to think of it, NFS probably
    > >>has interruptible read/write.
    > >>
    > >>In short: make the same policy for an interruptible and an uninterruptible
    > >>sleep.
    > >>
    > >
    > >That's the policy that has always existed...
    > >
    > >Interesting that I have only seen the desired effect and haven't noticed any
    >
    > >side effect from this change so far. I'll keep experimenting as much as
    > >possible (as if I wasn't going to) and see what the testers find as well.
    > >
    >
    > Oh, I'm not saying that your change is outright wrong, on the contrary I'd
    > say you have a better feel for what is needed than I do, but if you are
    > finding
    > that the uninterruptible sleep case needs some tweaking then the same tweak
    > should be applied to all sleep cases. If there really is a difference,
    > then its
    > just a fluke that the sleep paths in question use the type of sleep you are
    > testing for, and nothing more profound than that.

    Ah I see. It was from my observations of the behaviour of tasks in D that
    found it was the period spent in D that was leading to unfairness. The same
    tweak can't be applied to the rest of the sleeps because that inactivates
    everything. So it is a fluke that the thing I'm trying to penalise is what
    tasks in uninterruptible sleep do, but it is by backward observation of D
    tasks, not random chance.

    Con
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Andrew Morton: "Re: [PATCH] O11int for interactivity"

    Relevant Pages

    • Re: [PATCH] O13int for interactivity
      ... > Interesting that I have only seen the desired effect and haven't noticed any ... can submit more IO and go back to sleep. ... It's pretty sad if the CPU scheduler leaves the anticipated task ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [SCHED] wrong priority calc - SIMPLE test case
      ... 2 to begin treating all new sleep as noninteractive (stern ... These are all /proc settings at the moment, so I can set set my starvation ... pain threshold from super duper desktop to just as fair as a ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Post-halloween doc updates.
      ... > | have at least one working method of putting a laptop to sleep? ... > I have no problem putting the laptop to sleep. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: High CPU temp on Athlon MP w/ recent 2.6 kernels
      ... >haven't got time to contact devs with that, but I do know for sure that ... >AFAIK my xmms uses OSS emulation and rhytmbox is native alsa.) ... >easily we go into sleep. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [patch] stop inotify from sending random DELETE_SELF event under load
      ... >>sleep for a day ... That fd may be available to multiple processes, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)