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
> cpuinfo is needed t
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, becau
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
> > > wrote:
> > >> Current head + Raphaels patch:
> > >>
> > >> real0m0.
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 onl
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 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 somebody with 100+ cores tes
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 fre
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 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 wa
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 aperfmperf
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 show_cpuinfo(
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.
> >
> > For each cpu, arch_freq_get_on_
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 Ch
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: CPU:
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 perfor
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 eac
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 wi
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
/pro
23 matches
Mail list logo
