Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

From: hui (bhuey_at_lnxw.com)
Date: 02/02/05

  • Next message: Steven Pratt: "Re: [PATCH 3/4] readahead: factor out duplicated code" 
    Date:	Wed, 2 Feb 2005 13:34:02 -0800
To: Ingo Molnar <mingo@elte.hu>

    On Wed, Feb 02, 2005 at 10:21:00PM +0100, Ingo Molnar wrote:
    > yes and no. You are right in that the individual workloads (e.g.
    > softirqs) are not separated and identified/credited to the thread that
    > requested them. (in part due to the fact that you cannot e.g. credit a
    > thread for e.g. unrequested workloads like incoming sockets, or for
    > 'merged' workloads like writeout of a commonly accessed file.)

    What's not being addressed here is a need for pervasive QoS across all
    kernel systems. The power of this patch is multiplicative. It's not
    about a specific component of the system having microsecond latencies,
    it's about how all parts, softirqs, hardirqs, VM, etc... work together
    so that the entire system is suitable for (near) hard real time. It's
    unconstrained, unlike dual kernel RT systems, across all component
    boundaries. Those constraints create large chunks of glue logic between
    systems, which is exploded the complexity of things that app folks
    much deal with.

    This is where properly written Linux apps (non exist right now because
    of kernel issues) can really overtake competing apps from other OSes
    (ignoring how crappy X11 is).
     
    > but Jack is right in practical terms: the audio folks achieved pretty
    > good results with the current IRQ threading mechanism, partly due to the
    > fact that the audio stack doesnt use softirqs, so all the
    > latency-critical activities are in the audio IRQ thread and the
    > application itself.

    It's clever that they do that, but additional control is needed in the
    future. jackd isn't the most sophisticate media app on this planet (not
    too much of an insult :)) and the demands from this group is bound to
    increase as their group and competing projects get more and more
    sophisticated. When I mean kernel folks needs to be proactive, I really
    mean it. The Linux kernel latency issues and poor driver support is
    largely why media apps are way below even being second rate with regard
    to other operating systems such as Apple's OS X for instance.

    bill

    -
    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: Steven Pratt: "Re: [PATCH 3/4] readahead: factor out duplicated code"

    Relevant Pages

    • Re: .DS_Store
      ... So I just note that OSX can't handle this, ... what apps won't work, it doesn't help. ... characters" that aren't examined or used by anything in the kernel. ... tests have shown that most unix kernels ...
      (comp.sys.mac.apps)
    • Re: objrmap-core-1 (rmap removal for file mappings to avoid 4:4 in <=16G machines)
      ... >> I agree that works fine for Oracle, that's becase Oracle is an extreme ... >> not the case of other apps, and those other apps really depends on the ... >> kernel vm paging algorithms for things more than istantiating a pte ... no zone-normal shortage at all that I can remeber, ...
      (Linux-Kernel)
    • Re: [patch] x86, mm: pass in total to __copy_from_user_*nocache()
      ... then you still would want nontemporal stores. ... I dont disagree that it would be nice to handle that case too, ... the kernel can act on it reasonably. ... for important cases we allow apps to set attributes ...
      (Linux-Kernel)
    • Re: [Alsa-devel] OSS driver removal, 2nd round (v2)
      ... But OSS is kewl and ALSA sucks! ... If ALSA sucks, ... It's very interesting that with some apps aoss method ... But it must be done in kernel because kernel should know these ...
      (Linux-Kernel)
    • Re: queue_work from interrupt Real time preemption2.6.11-rc2-RT-V0.7.37-03
      ... We are not redesigning softirqs in any ... I'm only working on your PREEMPT_RT extension, ... the mainline kernel. ... I understand that the design of softirqs will not change for the mainline ...
      (Linux-Kernel)