lkml.org 
[lkml]   [2002]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Hotplug CPU Boot Changes: BEWARE
    From
    Date
    Rusty Russell <rusty@rustcorp.com.au> writes:

    > In message <m1elfjw39n.fsf@frodo.biederman.org> you write:
    > > But for the latter something just a little more than minimal hacks
    > > must be implemented. But dynamic cpu enable/disable is definitely
    > > worth it.
    >
    > Perhaps I didn't make myself clear: hotplugging does not neccessarily
    > mean physically removing or adding the CPU. And as to whether they
    > offer full support, or stub support, architectures can decide that for
    > themselves, as they need. It's not my call.

    I guess as long as the interface to user space is consistent I don't
    mind.

    > I don't know how much of a win it is to disable HT on cpus, but I can
    > tell you that adding & subtracting CPUs is a fairly heavy-weight
    > operation in this design (I don't think we really want to lock around
    > every cpu iteration).

    Agreed. However it should be lighter than a full system reboot,
    which is what is needed now. And if you can disable the extra
    cpu you can benchmark on the same machine without rebooting
    and see what kind of a win it is.

    My basic point was that with a name like hotplug it was not immediately
    clear this code could be useful for anything. And that there are a lot
    of debugging uses of being able stop or start a cpu. Things like is
    testing if HT/SMT worth it.

    For the kernel I fully expect this to be a heavy weight operation.
    But it is almost certainly lighter than swapoff /dev/hda1. Which
    makes it a lightweight operation for a system administrator.

    So it is my belief there is general usefulness of this code, on any
    SMP target. And with general applicability should come a common user
    space interface.

    On x86 the code to do dynamic start/stop should already exist,
    because we need it at kernel startup and shutdown. The code paths just
    need to be made safe to run at relatively arbitrary times. The
    generic part of which you are handling.

    Eric
    -
    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 13:26    [W:0.024 / U:0.916 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site