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

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

  • Next message: Matt Mackall: "dm-crypt crypt_status reports key?" 
    Date:	Wed, 2 Feb 2005 13:14:05 -0800
To: "Jack O'Quin" <joq@io.com>

    On Wed, Feb 02, 2005 at 10:44:22AM -0600, Jack O'Quin wrote:
    > Bill Huey (hui) <bhuey@lnxw.com> writes:
    > > Also, as media apps get more sophisticated they're going to need some
    > > kind of access to the some traditional softirq facilities, possibily
    > > migrating it into userspace safely somehow, with how it handles IO
    > > processing such as iSCSI, FireWire, networking and all peripherals
    > > that need some kind of prioritized IO handling. It's akin to O_DIRECT,
    > > where folks need to determine policy over the kernel's own facilities,
    > > IO queues, but in a more broad way. This is inevitable for these
    > > category of apps. Scary ? yes I know.
    >
    > I believe Ingo's RT patches already support this on a per-IRQ basis.
    > Each IRQ handler can run in a realtime thread with priority assigned
    > by the sysadmin. Balancing the interrupt handler priorities with
    > those of other realtime activities allows excellent control.

    No they don't. That's a physical mapping of these kernel entities, not a
    logic organization that projects upward to things like individual sockets
    or file streams. The current irq-thread patches are primarily for dealing
    with the low level acks and stuff for the devices in question. It does not
    deal with queuing policy or how these things are scheduler on a logical
    basis, which is what softirqs do. softirqs group a number of things together
    in one big uncontrollable chunk. Really, a bit of time spent in the kernel
    regarding this would clarify it more in the future. Don't speculate.

    This misunderstanding, often babble, from app folks is why kernel folks
    partially dismiss the needs requested from this subgroup. It's important
    to understand your needs before articulating it to a wider community.

    The kernel community must understand the true nature of these needs and
    then facilitate them. If the relationship is where kernel folks dictate
    what apps folks have, you basically pervert the relationbship and the
    responsiblities of overall development, which fatally cripples app
    and all development of this nature. It's a two way street, but kernel
    folks can be more proactive about it, definitely.

    Step one in this is to acknowlege that Unix scheduling semantics is
    "inantiquated" with regard to media apps. Some notion of scoping needs to
    be put in.

    Everybody on the same page ?

    > This is really only useful within the context of a dedicated realtime
    > system, of course.
    >
    > Stephane Letz reports a similar feature in Mac OS X.

    OS X is very coarse grained (two funnels) and I would seriously doubt
    that it would perform without scheduling side effects to the overall
    system because of that. With a largely stalled FreeBSD SMPng project
    where they hijack a good chunk of their code into an antiquate and
    bloated Mach threading system, that situation isn't helping it.

    What the Linux community has with the RT patches is potentially light
    years ahead of OS X regarding overall system latency, since RT and
    SMP performance is tightly related. It's just a matter of getting
    right folks to understand the problem space and then make changes so
    that the overall picture is completed.

    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: Matt Mackall: "dm-crypt crypt_status reports key?"

    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: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
      ... You are right in that the individual workloads (e.g. ... it's about how all parts, softirqs, hardirqs, VM, etc... ... unconstrained, unlike dual kernel RT systems, across all component ... This is where properly written Linux apps (non exist right now because ...
      (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)