On Wed, 15 Nov 2017, Linus Torvalds wrote:
> On Tue, Nov 14, 2017 at 11:43 PM, Ingo Molnar wrote:
> Again, try that "cat" example again, and time it.
>
> (And yes, I also know that "cpu*/cpufreq" is a symlink, but the direct
> names are illogical, and no faster for me. Try it
On Wed, 15 Nov 2017, Linus Torvalds wrote:
> On Tue, Nov 14, 2017 at 11:43 PM, Ingo Molnar wrote:
> Again, try that "cat" example again, and time it.
>
> (And yes, I also know that "cpu*/cpufreq" is a symlink, but the direct
> names are illogical, and no faster for me. Try it if you like:
>
>
On Tue, Nov 14, 2017 at 11:43 PM, Ingo Molnar wrote:
>
> I also think that /proc/cpuinfo is a pretty bad interface for many uses - I
> personally only very rarely need the cpuinfo of _all_ CPUs.
>
> We we should eventually have /proc/cpu/N/info or so, so that 99% of the times
>
On Tue, Nov 14, 2017 at 11:43 PM, Ingo Molnar wrote:
>
> I also think that /proc/cpuinfo is a pretty bad interface for many uses - I
> personally only very rarely need the cpuinfo of _all_ CPUs.
>
> We we should eventually have /proc/cpu/N/info or so, so that 99% of the times
> cpuinfo is needed
On Tue, 14 Nov 2017, Linus Torvalds wrote:
> On Tue, Nov 14, 2017 at 3:53 PM, Thomas Gleixner wrote:
> > Current head + Raphaels patch:
> >
> > real0m0.029s
> > user0m0.000s
> > sys 0m0.010s
> >
> > So that patch is actually slower.
>
> Oh it definitely is
On Tue, 14 Nov 2017, Linus Torvalds wrote:
> On Tue, Nov 14, 2017 at 3:53 PM, Thomas Gleixner wrote:
> > Current head + Raphaels patch:
> >
> > real0m0.029s
> > user0m0.000s
> > sys 0m0.010s
> >
> > So that patch is actually slower.
>
> Oh it definitely is expected to be slower,
On Wed, Nov 15, 2017 at 08:43:58AM +0100, Ingo Molnar wrote:
>
> * Rafael J. Wysocki wrote:
>
> > On Wednesday, November 15, 2017 1:06:12 AM CET Linus Torvalds wrote:
> > > On Tue, Nov 14, 2017 at 4:04 PM, Linus Torvalds
> > > wrote:
> > > >
On Wed, Nov 15, 2017 at 08:43:58AM +0100, Ingo Molnar wrote:
>
> * Rafael J. Wysocki wrote:
>
> > On Wednesday, November 15, 2017 1:06:12 AM CET Linus Torvalds wrote:
> > > On Tue, Nov 14, 2017 at 4:04 PM, Linus Torvalds
> > > wrote:
> > > > On Tue, Nov 14, 2017 at 3:53 PM, Thomas Gleixner
>
* Rafael J. Wysocki wrote:
> On Wednesday, November 15, 2017 1:06:12 AM CET Linus Torvalds wrote:
> > On Tue, Nov 14, 2017 at 4:04 PM, Linus Torvalds
> > wrote:
> > > On Tue, Nov 14, 2017 at 3:53 PM, Thomas Gleixner
> > >
* Rafael J. Wysocki wrote:
> On Wednesday, November 15, 2017 1:06:12 AM CET Linus Torvalds wrote:
> > On Tue, Nov 14, 2017 at 4:04 PM, Linus Torvalds
> > wrote:
> > > On Tue, Nov 14, 2017 at 3:53 PM, Thomas Gleixner
> > > wrote:
> > >> Current head + Raphaels patch:
> > >>
> > >> real
On Tue, Nov 14, 2017 at 4:30 PM, Rafael J. Wysocki wrote:
>
> OK, so may I queue it up?
>
> I don't think I can get that to work substantially faster anyway ...
Yeah, I think it's ok.
If somebody is really doing that /proc/cpuinfo in a loop, the rate
limiting should kick in.
On Tue, Nov 14, 2017 at 4:30 PM, Rafael J. Wysocki wrote:
>
> OK, so may I queue it up?
>
> I don't think I can get that to work substantially faster anyway ...
Yeah, I think it's ok.
If somebody is really doing that /proc/cpuinfo in a loop, the rate
limiting should kick in. And if you do it
On Wednesday, November 15, 2017 1:06:12 AM CET Linus Torvalds wrote:
> On Tue, Nov 14, 2017 at 4:04 PM, Linus Torvalds
> wrote:
> > On Tue, Nov 14, 2017 at 3:53 PM, Thomas Gleixner wrote:
> >> Current head + Raphaels patch:
> >>
> >> real
On Wednesday, November 15, 2017 1:06:12 AM CET Linus Torvalds wrote:
> On Tue, Nov 14, 2017 at 4:04 PM, Linus Torvalds
> wrote:
> > On Tue, Nov 14, 2017 at 3:53 PM, Thomas Gleixner wrote:
> >> Current head + Raphaels patch:
> >>
> >> real0m0.029s
> >> user0m0.000s
> >> sys 0m0.010s
>
On Tue, Nov 14, 2017 at 4:04 PM, Linus Torvalds
wrote:
> On Tue, Nov 14, 2017 at 3:53 PM, Thomas Gleixner wrote:
>> Current head + Raphaels patch:
>>
>> real0m0.029s
>> user0m0.000s
>> sys 0m0.010s
>>
>> So that patch is actually
On Tue, Nov 14, 2017 at 4:04 PM, Linus Torvalds
wrote:
> On Tue, Nov 14, 2017 at 3:53 PM, Thomas Gleixner wrote:
>> Current head + Raphaels patch:
>>
>> real0m0.029s
>> user0m0.000s
>> sys 0m0.010s
>>
>> So that patch is actually slower.
>
> Oh it definitely is expected to be slower,
On Wednesday, November 15, 2017 12:53:24 AM CET Thomas Gleixner wrote:
> On Tue, 14 Nov 2017, Linus Torvalds wrote:
>
> > On Tue, Nov 14, 2017 at 2:47 PM, Rafael J. Wysocki
> > wrote:
> > >
> > > So what about the one below? It works for me as expected.
> >
> > Can
On Wednesday, November 15, 2017 12:53:24 AM CET Thomas Gleixner wrote:
> On Tue, 14 Nov 2017, Linus Torvalds wrote:
>
> > On Tue, Nov 14, 2017 at 2:47 PM, Rafael J. Wysocki
> > wrote:
> > >
> > > So what about the one below? It works for me as expected.
> >
> > Can somebody with 100+ cores
On Tue, Nov 14, 2017 at 3:53 PM, Thomas Gleixner wrote:
> Current head + Raphaels patch:
>
> real0m0.029s
> user0m0.000s
> sys 0m0.010s
>
> So that patch is actually slower.
Oh it definitely is expected to be slower, because it does the IPI to
all the cores and
On Tue, Nov 14, 2017 at 3:53 PM, Thomas Gleixner wrote:
> Current head + Raphaels patch:
>
> real0m0.029s
> user0m0.000s
> sys 0m0.010s
>
> So that patch is actually slower.
Oh it definitely is expected to be slower, because it does the IPI to
all the cores and actually gets their
On Tue, 14 Nov 2017, Linus Torvalds wrote:
> On Tue, Nov 14, 2017 at 2:47 PM, Rafael J. Wysocki wrote:
> >
> > So what about the one below? It works for me as expected.
>
> Can somebody with 100+ cores test this? Ingo? You had a 160 core
> machine that took forever, didn't
On Tue, 14 Nov 2017, Linus Torvalds wrote:
> On Tue, Nov 14, 2017 at 2:47 PM, Rafael J. Wysocki wrote:
> >
> > So what about the one below? It works for me as expected.
>
> Can somebody with 100+ cores test this? Ingo? You had a 160 core
> machine that took forever, didn't you..
On a 144 CPUs
On Tue, Nov 14, 2017 at 2:47 PM, Rafael J. Wysocki wrote:
>
> So what about the one below? It works for me as expected.
Can somebody with 100+ cores test this? Ingo? You had a 160 core
machine that took forever, didn't you..
Linus
On Tue, Nov 14, 2017 at 2:47 PM, Rafael J. Wysocki wrote:
>
> So what about the one below? It works for me as expected.
Can somebody with 100+ cores test this? Ingo? You had a 160 core
machine that took forever, didn't you..
Linus
On Saturday, November 11, 2017 12:09:18 AM CET Rafael J. Wysocki wrote:
> On Fri, Nov 10, 2017 at 8:11 PM, Linus Torvalds
> wrote:
> > On Thu, Nov 9, 2017 at 2:30 PM, Rafael J. Wysocki wrote:
> >>
> >> c_start() can run aperfmperf_snapshot_khz()
On Saturday, November 11, 2017 12:09:18 AM CET Rafael J. Wysocki wrote:
> On Fri, Nov 10, 2017 at 8:11 PM, Linus Torvalds
> wrote:
> > On Thu, Nov 9, 2017 at 2:30 PM, Rafael J. Wysocki wrote:
> >>
> >> c_start() can run aperfmperf_snapshot_khz() on all CPUs upfront (say
> >> in parallel), then
On Fri, Nov 10, 2017 at 8:11 PM, Linus Torvalds
wrote:
> On Thu, Nov 9, 2017 at 2:30 PM, Rafael J. Wysocki wrote:
>>
>> c_start() can run aperfmperf_snapshot_khz() on all CPUs upfront (say
>> in parallel), then wait for a while (say 5 ms; the
On Fri, Nov 10, 2017 at 8:11 PM, Linus Torvalds
wrote:
> On Thu, Nov 9, 2017 at 2:30 PM, Rafael J. Wysocki wrote:
>>
>> c_start() can run aperfmperf_snapshot_khz() on all CPUs upfront (say
>> in parallel), then wait for a while (say 5 ms; the current 20 ms wait
>> is overkill) and then
On Thu, Nov 9, 2017 at 2:30 PM, Rafael J. Wysocki wrote:
>
> c_start() can run aperfmperf_snapshot_khz() on all CPUs upfront (say
> in parallel), then wait for a while (say 5 ms; the current 20 ms wait
> is overkill) and then aperfmperf_snapshot_khz() can be run once on
> each
On Thu, Nov 9, 2017 at 2:30 PM, Rafael J. Wysocki wrote:
>
> c_start() can run aperfmperf_snapshot_khz() on all CPUs upfront (say
> in parallel), then wait for a while (say 5 ms; the current 20 ms wait
> is overkill) and then aperfmperf_snapshot_khz() can be run once on
> each CPU in
On 11/10/17 at 08:25P, Ingo Molnar wrote:
>
> * Rafael J. Wysocki wrote:
>
> > Hi Linus,
> >
> > On 11/9/2017 11:38 AM, WANG Chao wrote:
> > > Commit 941f5f0f6ef5 (x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo) caused
> > > a serious performance issue when reading
On 11/10/17 at 08:25P, Ingo Molnar wrote:
>
> * Rafael J. Wysocki wrote:
>
> > Hi Linus,
> >
> > On 11/9/2017 11:38 AM, WANG Chao wrote:
> > > Commit 941f5f0f6ef5 (x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo) caused
> > > a serious performance issue when reading from /proc/cpuinfo on system
>
* Rafael J. Wysocki wrote:
> Hi Linus,
>
> On 11/9/2017 11:38 AM, WANG Chao wrote:
> > Commit 941f5f0f6ef5 (x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo) caused
> > a serious performance issue when reading from /proc/cpuinfo on system
> > with aperfmperf.
> >
> >
* Rafael J. Wysocki wrote:
> Hi Linus,
>
> On 11/9/2017 11:38 AM, WANG Chao wrote:
> > Commit 941f5f0f6ef5 (x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo) caused
> > a serious performance issue when reading from /proc/cpuinfo on system
> > with aperfmperf.
> >
> > For each cpu,
On 11/10/17 at 12:04P, WANG Chao wrote:
> On 11/10/17 at 01:06P, Rafael J. Wysocki wrote:
> > On Thursday, November 9, 2017 11:30:54 PM CET Rafael J. Wysocki wrote:
> > > On Thu, Nov 9, 2017 at 5:06 PM, Rafael J. Wysocki
> > > wrote:
> > > > Hi Linus,
> > > >
> > > >
On 11/10/17 at 12:04P, WANG Chao wrote:
> On 11/10/17 at 01:06P, Rafael J. Wysocki wrote:
> > On Thursday, November 9, 2017 11:30:54 PM CET Rafael J. Wysocki wrote:
> > > On Thu, Nov 9, 2017 at 5:06 PM, Rafael J. Wysocki
> > > wrote:
> > > > Hi Linus,
> > > >
> > > > On 11/9/2017 11:38 AM, WANG
On 11/10/17 at 01:06P, Rafael J. Wysocki wrote:
> On Thursday, November 9, 2017 11:30:54 PM CET Rafael J. Wysocki wrote:
> > On Thu, Nov 9, 2017 at 5:06 PM, Rafael J. Wysocki
> > wrote:
> > > Hi Linus,
> > >
> > > On 11/9/2017 11:38 AM, WANG Chao wrote:
> > >>
> > >>
On 11/10/17 at 01:06P, Rafael J. Wysocki wrote:
> On Thursday, November 9, 2017 11:30:54 PM CET Rafael J. Wysocki wrote:
> > On Thu, Nov 9, 2017 at 5:06 PM, Rafael J. Wysocki
> > wrote:
> > > Hi Linus,
> > >
> > > On 11/9/2017 11:38 AM, WANG Chao wrote:
> > >>
> > >> Commit 941f5f0f6ef5 (x86:
On Thursday, November 9, 2017 11:30:54 PM CET Rafael J. Wysocki wrote:
> On Thu, Nov 9, 2017 at 5:06 PM, Rafael J. Wysocki
> wrote:
> > Hi Linus,
> >
> > On 11/9/2017 11:38 AM, WANG Chao wrote:
> >>
> >> Commit 941f5f0f6ef5 (x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo)
On Thursday, November 9, 2017 11:30:54 PM CET Rafael J. Wysocki wrote:
> On Thu, Nov 9, 2017 at 5:06 PM, Rafael J. Wysocki
> wrote:
> > Hi Linus,
> >
> > On 11/9/2017 11:38 AM, WANG Chao wrote:
> >>
> >> Commit 941f5f0f6ef5 (x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo) caused
> >> a serious
On Thu, Nov 9, 2017 at 5:06 PM, Rafael J. Wysocki
wrote:
> Hi Linus,
>
> On 11/9/2017 11:38 AM, WANG Chao wrote:
>>
>> Commit 941f5f0f6ef5 (x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo) caused
>> a serious performance issue when reading from /proc/cpuinfo on system
>>
On Thu, Nov 9, 2017 at 5:06 PM, Rafael J. Wysocki
wrote:
> Hi Linus,
>
> On 11/9/2017 11:38 AM, WANG Chao wrote:
>>
>> Commit 941f5f0f6ef5 (x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo) caused
>> a serious performance issue when reading from /proc/cpuinfo on system
>> with aperfmperf.
>>
>> For
Hi Linus,
On 11/9/2017 11:38 AM, WANG Chao wrote:
Commit 941f5f0f6ef5 (x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo) caused
a serious performance issue when reading from /proc/cpuinfo on system
with aperfmperf.
For each cpu, arch_freq_get_on_cpu() sleeps 20ms to get its frequency.
On a system
Hi Linus,
On 11/9/2017 11:38 AM, WANG Chao wrote:
Commit 941f5f0f6ef5 (x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo) caused
a serious performance issue when reading from /proc/cpuinfo on system
with aperfmperf.
For each cpu, arch_freq_get_on_cpu() sleeps 20ms to get its frequency.
On a system
Commit 941f5f0f6ef5 (x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo) caused
a serious performance issue when reading from /proc/cpuinfo on system
with aperfmperf.
For each cpu, arch_freq_get_on_cpu() sleeps 20ms to get its frequency.
On a system with 64 cpus, it takes 1.5s to finish running `cat
Commit 941f5f0f6ef5 (x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo) caused
a serious performance issue when reading from /proc/cpuinfo on system
with aperfmperf.
For each cpu, arch_freq_get_on_cpu() sleeps 20ms to get its frequency.
On a system with 64 cpus, it takes 1.5s to finish running `cat
46 matches
Mail list logo