[lkml]   [2004]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: [RFC][PATCH] O(1) Entitlement Based Scheduler
    At a previous employer (so code not available) I used a simple expedient to
    solve this very problem. I had a custom program "shim.c" that tweaked
    priorities and environment variables. Basically a fistful of lines that
    would take argv[0], look for the file named ".shim_"+basename(argv[0]) {in a
    well-defined location} to load some simple environment and path and priority
    overrides, apply these changes and then setuid itself back to the real user
    and exec() the real program with the received args.

    It had some few degenerate cases (shmming out from under a setuid program
    was the primary one) but it worked out rather well and had little-to-no
    meaningful overhead.

    You set up a /usr/local/bin (or equivalent) directory, link shim into that
    directory named as the various programs that need to be boosted (e.g. xmms
    etc) and put that directory earlier on the path than the real executable.
    {If this directory only contains shims, it is useful to code shim.c to
    remove that directory from the PATH.)

    This technique lets the administrator have fine-grained control of a
    reasonable list of priority promotions and permissions overrides without
    having to move anything into kernel space or running status daemons.


    I would think that while fork() should keep the heuristics of its parent,
    exec() would probably need to do some normalizing.


    Has this scheduler been tried for applications like CD burning?


    -----Original Message-----
    [] On Behalf Of Peter Williams
    Sent: Wednesday, February 25, 2004 6:18 PM
    To: Timothy Miller
    Subject: Re: [RFC][PATCH] O(1) Entitlement Based Scheduler

    Timothy Miller wrote:
    > <snip>
    > In fact, that may be the only "flaw" in your design. It sounds like
    > your scheduler does an excellent job at fairness with very low overhead.
    > The only problem with it is that it doesn't determine priority
    > dynamically.

    This (i.e. automatic renicing of specified programs) is a good idea but
    is not really a function that should be undertaken by the scheduler
    itself. Two possible solutions spring to mind:

    1. modify the do_execve() in fs/exec.c to renice tasks when they execute
    specified binaries
    2. have a user space daemon poll running tasks periodically and renice
    them if they are running specified binaries

    Both of these solutions have their advantages and disadvantages, are
    (obviously) complicated than I've made them sound and would require a
    great deal of care to be taken during their implementation. However, I
    think that they are both doable. My personal preference would be for
    the in kernel solution on the grounds of efficiency.

    Dr Peter Williams, Chief Scientist
    Aurema Pty Limited Tel:+61 2 9698 2322
    PO Box 305, Strawberry Hills NSW 2012, Australia Fax:+61 2 9699 9174
    79 Myrtle Street, Chippendale NSW 2008, Australia

    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

    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 14:01    [W:0.023 / U:36.892 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site