Re: [RFC][PATCH] O(1) Entitlement Based Scheduler

From: Pavel Machek (pavel_at_ucw.cz)
Date: 02/25/04

  • Next message: Jean-Luc Cooke: "Re: cryptoapi OMAC (was: cryptoapi highmem bug)" 
    Date:	Wed, 25 Feb 2004 23:51:59 +0100
To: John Lee <johnl@aurema.com>

    Hi!

    > CPU usage rate caps
    > -------------------
    >
    > A task's CPU usage rate cap imposes a soft (or hard) upper limit on the rate at
    > which it can use CPU resources and can be set/read via the files
    >
    > /proc/<pid>/cpu_rate_cap
    > /proc/<tgid>/task/<pid>/cpu_rate_cap
    >
    > Usage rate caps are expressed as rational numbers (e.g. "1 / 2") and hard caps
    > are signified by a "!" suffix. The rational number indicates the proportion
    > of a single CPU's capacity that the task may use. The value of the number must
    > be in the range 0.0 to 1.0 inclusive for soft caps. For hard caps there is an
    > additional restriction that a value of 0.0 is not permitted. Tasks with a
    > soft cap of 0.0 become true background tasks and only get to run when no other
    > tasks are active.

    Why not use something like percent, parts per milion or whatever?

    > When hard capped tasks exceed their cap they are removed from the run queues
    > and placed in a "sinbin" for a short while until their usage rate decays to
    > within limits.

    How do you solve this one?

    I want to kill your system.

    I launch task A, "semaphore grabber", that does filesystem
    operations. Those need semaphores. I run it as "true background".

    I wait for A to grab some lock, then I run B, which is while(1);

    A holds lock that can not be unlocked, and your system is dead.

    This may happen randomly, even without me on your system.
                                                                    Pavel 

    -- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
-
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: Jean-Luc Cooke: "Re: cryptoapi OMAC (was: cryptoapi highmem bug)"