lkml.org 
[lkml]   [2005]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.6.11-rc2-mm2
    Andrew Morton wrote:
    >
    > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc2/2.6.11-rc2-mm2/
    >
    >
    >
    >
    > Changes since 2.6.11-rc2-mm1:
    >

    Just a couple of things:

    > +task_size-is-variable.patch
    > +use-mm_vm_size-in-exit_mmap.patch
    >

    I didn't hear back about my comments on this patch. I don't see
    why MM_VM_SIZE should round up to the next PGDIR? This means
    architecture implementations need to do the same thing, yes?

    If MM_VM_SIZE means "the total address span of all top level page
    tables an mm can contain", then OK. Otherwise it should probably
    be left in the caller.

    > Fixes for recent TASK_SIZE changes (these are still in flux)
    >
    ^^^
    Oh, I see :P

    >
    > -sched-isochronous-class-for-unprivileged-soft-rt-scheduling.patch
    > -sched-account-rt_tasks-as-iso_ticks.patch
    > +rlimit_rt_cpu.patch
    > +rlimit_rt_cpu-fix.patch
    > +rlimit_rt_cpu-sparc64-fix.patch
    >
    > Drop SCHED_ISO, add the rlimit which allows non-privileged users to gain
    > limited RT scheduling policy.
    >

    At the risk of sounding like a luddite who doesn't want to see a
    complex new userspace API introduced that we're forced to support
    for the next 10 years... I have some valid concerns with the rt
    limit patches.

    A simple rlimit of RT priorities (a very well definied quantity,
    in contrast the vague "CPU usage"), is easy, a patch exists, it
    doesn't touch a single fastpath or add complexity, it immediately
    addresses the concerns of the RT audio guys who started all this,
    and can be used meaningfully by userspace systems that want to
    control and limit *real* RT scheduling, and without breaking
    defined userspace RT scheduling APIs, IMO would be a better place
    to start.

    If someone later comes along and wants the extra features and
    quirks that these patches provide, then I'd be all for further work
    and discussion.

    And this isn't meant to be an attack on anyone - I'm aware that
    the -mm tree is for testing and discussion and further progression
    of patches.


    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 14:10    [W:0.034 / U:29.260 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site