Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1666931
| From | Alexey Budankov <alexey.budankov@linux.intel.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v2]: perf/core: addressing 4x slowdown during per-process, profiling of STREAM benchmark on Intel Xeon Phi |
| Date | 2017-06-15 19:50 +0200 |
| Message-ID | <tSH45-5q5-7@gated-at.bofh.it> (permalink) |
| References | (3 earlier) <tMp0f-6bg-47@gated-at.bofh.it> <tMqpk-72M-15@gated-at.bofh.it> <tMqz0-77t-11@gated-at.bofh.it> <tMr22-7Aq-23@gated-at.bofh.it> <tMrlo-7Ii-17@gated-at.bofh.it> |
| Organization | Intel Corp. |
On 29.05.2017 14:45, Alexey Budankov wrote: > On 29.05.2017 14:23, Peter Zijlstra wrote: >> On Mon, May 29, 2017 at 01:56:05PM +0300, Alexey Budankov wrote: >>> On 29.05.2017 13:43, Peter Zijlstra wrote: >> >>>> Why can't the tree do both? >>>> >>> >>> Well, indeed, the tree provides such capability too. However >>> switching to >>> the full tree iteration in cases where we now go through _groups >>> lists will >>> enlarge the patch, what is probably is not a big deal. Do you think >>> it is >>> worth implementing the switch? >> >> Do it as a series of patches, where patch 1 introduces the tree, patches >> 2 through n convert the list users into tree users, and patch n+1 >> removes the list. > > Well ok, let's do that additionally but please expect delay in delivery > (I am OOO till Jun 14). addressed in v3. > >> >> I think its good to not have duplicate data structures if we can avoid >> it. >> > > yeah, makes sense. > > >
Back to linux.kernel | Previous | Next | Find similar | Unroll thread
Re: [PATCH v2]: perf/core: addressing 4x slowdown during per-process, profiling of STREAM benchmark on Intel Xeon Phi Alexey Budankov <alexey.budankov@linux.intel.com> - 2017-06-15 19:50 +0200
csiph-web