lkml.org 
[lkml]   [1999]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: RasterMan on linux and threads
    Date

    > Nope. He just doesn't know anything about scheduling (or threading).
    > Moving a thread to a different processor is almost always a loss in
    > the real world (ie except for very long-lived threads with one thread
    > per proc on an otherwise idle box), because it means that not only do
    > you have the cost of migrating the process to the other processor, but
    > you lose cache-affinity (you need to save and restore as much context
    > as seperate processes whereas if they share a processor, all the
    > process data is in the processor cache for all threads to share
    > without cache misses).

    That assumes that the two threads are sharing a lot of changing context
    data. If that were true, no other method will be more efficient than
    multithreading. Shared memory, for example, will be no more efficient.

    > It also means that other processes suffer,
    > because your one multi-threaded process (in the case of 2-way SMP)
    > would get twice as many context switches (each thread would need to
    > get swapped in and out seperately per processor),

    If you care about performance, you shouldn't care about this.
    High-performance news servers don't worry about starving a web serving
    program. High-performance name servers don't worry about starving a mail
    program. Again, the alternative (multiple processes) would cause the same
    problem.

    > and introduces lots
    > of luvverly atomicity nasties, because process data (visible to all
    > threads) needs to be available to all processors. Summary: Ouch.

    Not so either. Caches handle shared unchanging data just fine.

    Overall -- Nonesense. If you're considering multiple threads or multiple
    processors, multiple threads are a win all around.

    1) You might have fewer context switches. A thread that can keep picking up
    whatever work happens to need to be done can run longer than a process that
    can only do work for a single connection/job.

    2) You might have less expensive context switches. Thread context switches
    will require less work since the vm won't change.

    3) You might be more responsive. In a multiprocess solution, an ambushed
    process will freeze whatever work was assigned to that connection. In a
    multithreaded solution, it will only stall the job that thread was doing --
    other jobs can then be taken over by other threads.

    There are several other factors that weigh in favor or threads, but these
    are probably the three biggest.

    DS


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:55    [W:0.024 / U:59.868 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site