lkml.org 
[lkml]   [2006]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: cpusets not cpu hotplug aware

    Hi,

    > Your query confuses me, about 4 different ways ...
    >
    > 1) What does sched_setaffinity have to do with this part of cpusets?

    long sched_setaffinity(pid_t pid, cpumask_t new_mask)
    {
    ...
    cpus_allowed = cpuset_cpus_allowed(p);
    cpus_and(new_mask, new_mask, cpus_allowed);
    retval = set_cpus_allowed(p, new_mask);

    If cpuset_cpus_allowed doesnt return the current online mask and we want
    to schedule on a cpu that has been added since boot it looks like we
    will fail.

    > 2) What did you mean by "statically assigned"? At boot, whatever cpus
    > and memory nodes are online are copied to the top_cpuset's settings.
    > As Simon suggests, it would be up to the hotplug/hotunplug folks to
    > update these top_cpuset settings, as cpus and nodes come and go.

    Its up to the cpusets code to register a hotplug notifier to update the
    top_cpuset maps.

    > 3) I don't understand what you thought was suspicious here.
    > 4) I don't understand what you expected to see instead here.

    If the top level cpuset pointed to cpu_online_map instead of a boot time
    copy we wouldnt need any hotplug gunk in the cpusets code.

    Maybe the notifier is the right way to go, but it seems strange to
    create two copies of cpu_online_map (with the associated possibiliy of
    the two getting out of sync).

    Anton
    -
    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: 2006-08-21 21:25    [W:4.828 / U:0.112 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site