On December 10, 2015 5:01:18 PM GMT+09:00, Ingo Molnar <[email protected]> wrote: > >* Namhyung Kim <[email protected]> wrote: > >> Hello, >> >> This patchset if an attempt to support multi-threading in perf top. >> In fact, perf top already run on two threads - a worker thread and a >> display thread. However processing all samples with a single thread >> in a large machine can have scalability problems. >> >> This patchset extends it to have multiple worker threads to process >> samples concurrently. Users can control the number of threads using >> --num-thread option. And there's a collector thread for passing >hist >> entries from worker threads to the display thread. > >Could you please make the number of threads default to the number of >CPUs? > >Since perf top is doing one perf event per CPU anyway, that's a pretty >natural >model. > >( I think 'perf record' should use per CPU threads as well to receive >events, to >address the 'IO overload' problems with -g recording on larger CPU >counts. )
IIRC David said that thread per cpu seems too much especially on a large system (like ~1024 cpu). I have no idea what's the reasonable default on the system, so I chose 1/4 of map buffers (i.e. cpus for most cases). But I think I should take non-system-wide mode into account too. Thanks Namhyung Hi Ingo, -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
