On Thu, Apr 01, 2021 at 11:31:56AM -0400, Alex Kogan wrote:
> This performance optimization chooses probabilistically to avoid moving
> threads from the main queue into the secondary one when the secondary queue
> is empty.
>
> It is helpful when the lock is only lightly contended. In particular,
For the sake of completeness following are given the remaining sets of
kernbench results related to this thread.
Setup for kernbench test is as described in previous mails but now all
120 logical CPUs were online in all tests. Test runs were still pinned
to node 0.
Common legend for below tables
For the sake of completeness following are given the remaining sets of
kernbench results related to this thread.
Setup for kernbench test is as described in previous mails but now all
120 logical CPUs were online in all tests. Test runs were still pinned
to node 0.
Common legend for below tables
On Wed, Jul 18, 2018 at 05:25:56PM +0200, Andreas Herrmann wrote:
...
> Average mean for user/system/elapsed time and standard deviation for each
Oops, of course I meant arithmetic mean.
...
On Wed, Jul 18, 2018 at 05:25:56PM +0200, Andreas Herrmann wrote:
...
> Average mean for user/system/elapsed time and standard deviation for each
Oops, of course I meant arithmetic mean.
...
I think I still owe some performance numbers to show what is wrong
with systems using pcc-cpufreq with Linux after commit 554c8aa8ecad.
Following are results for kernbench tests (from MMTests test suite).
That's just a kernel compile with different number of compile jobs.
As result the time is
I think I still owe some performance numbers to show what is wrong
with systems using pcc-cpufreq with Linux after commit 554c8aa8ecad.
Following are results for kernbench tests (from MMTests test suite).
That's just a kernel compile with different number of compile jobs.
As result the time is
ze if intel_pstate has
> been registered already.
>
> Fixes: fbbcdc0744da (intel_pstate: skip the driver if ACPI has power mgmt
> option)
> Reported-by: Andreas Herrmann
> Reviewed-by: Andreas Herrmann
> Acked-by: Srinivas Pandruvada
> Signed-off-by: Rafael J. Wysocki
> ---
ze if intel_pstate has
> been registered already.
>
> Fixes: fbbcdc0744da (intel_pstate: skip the driver if ACPI has power mgmt
> option)
> Reported-by: Andreas Herrmann
> Reviewed-by: Andreas Herrmann
> Acked-by: Srinivas Pandruvada
> Signed-off-by: Rafael J. Wysocki
> ---
On Wed, Jul 18, 2018 at 10:23:52AM +0200, Peter Zijlstra wrote:
> On Tue, Jul 17, 2018 at 10:13:23PM +0200, Andreas Herrmann wrote:
> > On Tue, Jul 17, 2018 at 06:14:58PM +0200, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki
> > >
> > > The firmwa
On Wed, Jul 18, 2018 at 10:23:52AM +0200, Peter Zijlstra wrote:
> On Tue, Jul 17, 2018 at 10:13:23PM +0200, Andreas Herrmann wrote:
> > On Tue, Jul 17, 2018 at 06:14:58PM +0200, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki
> > >
> > > The firmwa
ded performance.
>
> For this reason, disable dynamic CPU performance scaling on systems
> with pcc-cpufreq where the number of CPUs present at the driver init
> time is greater than 4. Also make the driver print corresponding
> complaints to the kernel log.
>
> Reported-by: Andreas
ded performance.
>
> For this reason, disable dynamic CPU performance scaling on systems
> with pcc-cpufreq where the number of CPUs present at the driver init
> time is greater than 4. Also make the driver print corresponding
> complaints to the kernel log.
>
> Reported-by: Andreas
On Tue, Jul 17, 2018 at 12:21:36PM +0200, Andreas Herrmann wrote:
> On Tue, Jul 17, 2018 at 12:09:21PM +0200, Rafael J. Wysocki wrote:
---8<---
> > OK, the patch is below.
> >
> > First, I hope that if "Collaborative Power Control" is disabled, it will
>
On Tue, Jul 17, 2018 at 12:21:36PM +0200, Andreas Herrmann wrote:
> On Tue, Jul 17, 2018 at 12:09:21PM +0200, Rafael J. Wysocki wrote:
---8<---
> > OK, the patch is below.
> >
> > First, I hope that if "Collaborative Power Control" is disabled, it will
>
On Tue, Jul 17, 2018 at 12:09:21PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, July 17, 2018 11:36:20 AM CEST Andreas Herrmann wrote:
> > On Tue, Jul 17, 2018 at 11:27:21AM +0200, Andreas Herrmann wrote:
> > > On Tue, Jul 17, 2018 at 11:23:25AM +0200, Rafael J. Wysocki wrote:
&
On Tue, Jul 17, 2018 at 12:09:21PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, July 17, 2018 11:36:20 AM CEST Andreas Herrmann wrote:
> > On Tue, Jul 17, 2018 at 11:27:21AM +0200, Andreas Herrmann wrote:
> > > On Tue, Jul 17, 2018 at 11:23:25AM +0200, Rafael J. Wysocki wrote:
&
On Tue, Jul 17, 2018 at 11:36:20AM +0200, Andreas Herrmann wrote:
> On Tue, Jul 17, 2018 at 11:27:21AM +0200, Andreas Herrmann wrote:
> > On Tue, Jul 17, 2018 at 11:23:25AM +0200, Rafael J. Wysocki wrote:
> > > On Tue, Jul 17, 2018 at 11:11 AM, Andreas Herrmann
> > >
On Tue, Jul 17, 2018 at 11:36:20AM +0200, Andreas Herrmann wrote:
> On Tue, Jul 17, 2018 at 11:27:21AM +0200, Andreas Herrmann wrote:
> > On Tue, Jul 17, 2018 at 11:23:25AM +0200, Rafael J. Wysocki wrote:
> > > On Tue, Jul 17, 2018 at 11:11 AM, Andreas Herrmann
> > >
On Tue, Jul 17, 2018 at 11:27:21AM +0200, Andreas Herrmann wrote:
> On Tue, Jul 17, 2018 at 11:23:25AM +0200, Rafael J. Wysocki wrote:
> > On Tue, Jul 17, 2018 at 11:11 AM, Andreas Herrmann
> > wrote:
> > > On Tue, Jul 17, 2018 at 11:06:29AM +0200, Rafael J. Wysocki wrot
On Tue, Jul 17, 2018 at 11:27:21AM +0200, Andreas Herrmann wrote:
> On Tue, Jul 17, 2018 at 11:23:25AM +0200, Rafael J. Wysocki wrote:
> > On Tue, Jul 17, 2018 at 11:11 AM, Andreas Herrmann
> > wrote:
> > > On Tue, Jul 17, 2018 at 11:06:29AM +0200, Rafael J. Wysocki wrot
On Tue, Jul 17, 2018 at 11:23:25AM +0200, Rafael J. Wysocki wrote:
> On Tue, Jul 17, 2018 at 11:11 AM, Andreas Herrmann wrote:
> > On Tue, Jul 17, 2018 at 11:06:29AM +0200, Rafael J. Wysocki wrote:
> >> On Tue, Jul 17, 2018 at 10:50 AM, Andreas Herrmann
> >
On Tue, Jul 17, 2018 at 11:23:25AM +0200, Rafael J. Wysocki wrote:
> On Tue, Jul 17, 2018 at 11:11 AM, Andreas Herrmann wrote:
> > On Tue, Jul 17, 2018 at 11:06:29AM +0200, Rafael J. Wysocki wrote:
> >> On Tue, Jul 17, 2018 at 10:50 AM, Andreas Herrmann
> >
On Tue, Jul 17, 2018 at 11:06:29AM +0200, Rafael J. Wysocki wrote:
> On Tue, Jul 17, 2018 at 10:50 AM, Andreas Herrmann wrote:
>
> [cut]
>
> >
> > On balance before this commit users could use pcc-cpufreq but had
> > already suboptimal performance (compared to say
On Tue, Jul 17, 2018 at 11:06:29AM +0200, Rafael J. Wysocki wrote:
> On Tue, Jul 17, 2018 at 10:50 AM, Andreas Herrmann wrote:
>
> [cut]
>
> >
> > On balance before this commit users could use pcc-cpufreq but had
> > already suboptimal performance (compared to say
On Tue, Jul 17, 2018 at 10:15:07AM +0200, Peter Zijlstra wrote:
> On Tue, Jul 17, 2018 at 08:50:48AM +0200, Andreas Herrmann wrote:
> > I've recently noticed that commit 554c8aa8ecad ("sched: idle: Select
> > idle state before stopping the tick") causes severe perform
On Tue, Jul 17, 2018 at 10:15:07AM +0200, Peter Zijlstra wrote:
> On Tue, Jul 17, 2018 at 08:50:48AM +0200, Andreas Herrmann wrote:
> > I've recently noticed that commit 554c8aa8ecad ("sched: idle: Select
> > idle state before stopping the tick") causes severe perform
On Tue, Jul 17, 2018 at 10:03:41AM +0200, Rafael J. Wysocki wrote:
> On Tue, Jul 17, 2018 at 9:33 AM, Rafael J. Wysocki wrote:
> > Hi,
> >
> > Thanks for your report!
> >
> > On Tue, Jul 17, 2018 at 8:50 AM, Andreas Herrmann
> > wrote:
> >> He
On Tue, Jul 17, 2018 at 10:03:41AM +0200, Rafael J. Wysocki wrote:
> On Tue, Jul 17, 2018 at 9:33 AM, Rafael J. Wysocki wrote:
> > Hi,
> >
> > Thanks for your report!
> >
> > On Tue, Jul 17, 2018 at 8:50 AM, Andreas Herrmann
> > wrote:
> >> He
On Tue, Jul 17, 2018 at 09:33:53AM +0200, Rafael J. Wysocki wrote:
> Hi,
>
> Thanks for your report!
>
> On Tue, Jul 17, 2018 at 8:50 AM, Andreas Herrmann wrote:
> > Hello,
> >
> > I've recently noticed that commit 554c8aa8ecad ("sched: idle: Select
&
On Tue, Jul 17, 2018 at 09:33:53AM +0200, Rafael J. Wysocki wrote:
> Hi,
>
> Thanks for your report!
>
> On Tue, Jul 17, 2018 at 8:50 AM, Andreas Herrmann wrote:
> > Hello,
> >
> > I've recently noticed that commit 554c8aa8ecad ("sched: idle: Select
&
Hello,
I've recently noticed that commit 554c8aa8ecad ("sched: idle: Select
idle state before stopping the tick") causes severe performance drop
for systems using pcc-cpufreq driver. Depending on the number of CPUs
the system might be almost unusable. The OS jitter for 4.17.y and
4.18.-rcx
Hello,
I've recently noticed that commit 554c8aa8ecad ("sched: idle: Select
idle state before stopping the tick") causes severe performance drop
for systems using pcc-cpufreq driver. Depending on the number of CPUs
the system might be almost unusable. The OS jitter for 4.17.y and
4.18.-rcx
On Mon, Jul 24, 2017 at 04:44:45PM +0200, Borislav Petkov wrote:
> On Mon, Jul 24, 2017 at 09:14:18PM +0700, Suravee Suthikulpanit wrote:
> > Actually, this is not totally accurate. My apology. This patch is
> > mainly fix to incorrect core ID in /proc/cpuinfo.
>
> So you're "fixing" only some
On Mon, Jul 24, 2017 at 04:44:45PM +0200, Borislav Petkov wrote:
> On Mon, Jul 24, 2017 at 09:14:18PM +0700, Suravee Suthikulpanit wrote:
> > Actually, this is not totally accurate. My apology. This patch is
> > mainly fix to incorrect core ID in /proc/cpuinfo.
>
> So you're "fixing" only some
On Mon, Apr 10, 2017 at 11:55:43AM +0200, Paolo Valente wrote:
>
> > Il giorno 10 apr 2017, alle ore 11:05, Andreas Herrmann
> > <aherrm...@suse.com> ha scritto:
> >
> > Hi Paolo,
> >
> > I've looked at your WIP branch as of 4.11.0-bfq-mq-
On Mon, Apr 10, 2017 at 11:55:43AM +0200, Paolo Valente wrote:
>
> > Il giorno 10 apr 2017, alle ore 11:05, Andreas Herrmann
> > ha scritto:
> >
> > Hi Paolo,
> >
> > I've looked at your WIP branch as of 4.11.0-bfq-mq-rc4-00155-gbce0818
> > a
Hi Paolo,
I've looked at your WIP branch as of 4.11.0-bfq-mq-rc4-00155-gbce0818
and did some fio tests to compare the behavior to CFQ.
My understanding is that bfq-mq is supposed to be merged sooner or
later and then it will be the only reasonable I/O scheduler with
blk-mq for rotational
Hi Paolo,
I've looked at your WIP branch as of 4.11.0-bfq-mq-rc4-00155-gbce0818
and did some fio tests to compare the behavior to CFQ.
My understanding is that bfq-mq is supposed to be merged sooner or
later and then it will be the only reasonable I/O scheduler with
blk-mq for rotational
On Wed, Oct 05, 2016 at 09:31:18AM +0530, Viresh Kumar wrote:
> On 23-09-16, 19:02, Andreas Herrmann wrote:
> > Introduce op for ondemand governor that is used to map load to
> > frequency. It allows a cpufreq driver to provide a specific mapping
> > function if the generic fu
On Wed, Oct 05, 2016 at 09:31:18AM +0530, Viresh Kumar wrote:
> On 23-09-16, 19:02, Andreas Herrmann wrote:
> > Introduce op for ondemand governor that is used to map load to
> > frequency. It allows a cpufreq driver to provide a specific mapping
> > function if the generic fu
On Wed, Oct 05, 2016 at 10:47:53AM +0530, Viresh Kumar wrote:
> Sorry for being late Andreas :(
>
> On 14-09-16, 16:56, Andreas Herrmann wrote:
>
> First of all, thanks for your hardwork in getting these numbers out.
> Really appreciate it.
>
> > Below is some trace
On Wed, Oct 05, 2016 at 10:47:53AM +0530, Viresh Kumar wrote:
> Sorry for being late Andreas :(
>
> On 14-09-16, 16:56, Andreas Herrmann wrote:
>
> First of all, thanks for your hardwork in getting these numbers out.
> Really appreciate it.
>
> > Below is some trace
3308.80399.48 49.13 12.80 3505.80
120413.61 49.06 14.54 3181.00406.52 46.89 13.60 3331.60
Link: https://marc.info/?i=20160819121814.GA17296%40suselix.suse.de
Signed-off-by: Andreas Herrmann <aherrm...@suse.com>
---
drivers/cpufreq/Kconfig.x86 | 2 +-
drivers/c
3308.80399.48 49.13 12.80 3505.80
120413.61 49.06 14.54 3181.00406.52 46.89 13.60 3331.60
Link: https://marc.info/?i=20160819121814.GA17296%40suselix.suse.de
Signed-off-by: Andreas Herrmann
---
drivers/cpufreq/Kconfig.x86 | 2 +-
drivers/cpufreq/pcc-cpufreq.c | 11
3308.80399.48 49.13 12.80 3505.80
120413.61 49.06 14.54 3181.00406.52 46.89 13.60 3331.60
Link: https://marc.info/?i=20160819121814.GA17296%40suselix.suse.de
Signed-off-by: Andreas Herrmann <aherrm...@suse.com>
---
drivers/cpufreq/pcc-cpufreq.c | 11 +++
3308.80399.48 49.13 12.80 3505.80
120413.61 49.06 14.54 3181.00406.52 46.89 13.60 3331.60
Link: https://marc.info/?i=20160819121814.GA17296%40suselix.suse.de
Signed-off-by: Andreas Herrmann
---
drivers/cpufreq/pcc-cpufreq.c | 11 +++
1 file changed, 11
didn't show
significant performance differences between these two kernel versions.
Link: https://marc.info/?i=20160819121814.GA17296%40suselix.suse.de
Signed-off-by: Andreas Herrmann <aherrm...@suse.com>
---
drivers/cpufreq/cpufreq_governor.h | 5 +
drivers/cpufreq/cpufreq_ondemand.
didn't show
significant performance differences between these two kernel versions.
Link: https://marc.info/?i=20160819121814.GA17296%40suselix.suse.de
Signed-off-by: Andreas Herrmann
---
drivers/cpufreq/cpufreq_governor.h | 5 +
drivers/cpufreq/cpufreq_ondemand.c | 35
Hi,
following patches address the performance degradation due to commit
6393d6a102 (cpufreq: ondemand: Eliminate the deadband effect) on
systems using pcc-cpufreq driver and ondemand governor.
Patch 1 introduces a generic_map_load_to_freq function which is
similar to what is used since commit
Hi,
following patches address the performance degradation due to commit
6393d6a102 (cpufreq: ondemand: Eliminate the deadband effect) on
systems using pcc-cpufreq driver and ondemand governor.
Patch 1 introduces a generic_map_load_to_freq function which is
similar to what is used since commit
On Mon, Sep 19, 2016 at 10:39:18PM +0300, Stratos Karafotis wrote:
> On Mon, Sep 19, 2016 at 7:16 PM, Andreas Herrmann <aherrm...@suse.com> wrote:
> > On Fri, Sep 16, 2016 at 09:58:42PM +0300, Stratos Karafotis wrote:
> >> Hi,
> >>
> >> [ I 'm re
On Mon, Sep 19, 2016 at 10:39:18PM +0300, Stratos Karafotis wrote:
> On Mon, Sep 19, 2016 at 7:16 PM, Andreas Herrmann wrote:
> > On Fri, Sep 16, 2016 at 09:58:42PM +0300, Stratos Karafotis wrote:
> >> Hi,
> >>
> >> [ I 'm resending this message, be
On Fri, Sep 16, 2016 at 09:58:42PM +0300, Stratos Karafotis wrote:
> Hi,
>
> [ I 'm resending this message, because I think some recipients didn't receive
> it. ]
>
> On 16/09/2016 12:47 μμ, Andreas Herrmann wrote:
> > On Wed, Sep 07, 2016 at 10:32:01AM +0530, Viresh Ku
On Fri, Sep 16, 2016 at 09:58:42PM +0300, Stratos Karafotis wrote:
> Hi,
>
> [ I 'm resending this message, because I think some recipients didn't receive
> it. ]
>
> On 16/09/2016 12:47 μμ, Andreas Herrmann wrote:
> > On Wed, Sep 07, 2016 at 10:32:01AM +0530, Viresh Ku
On Wed, Sep 07, 2016 at 10:32:01AM +0530, Viresh Kumar wrote:
> On 01-09-16, 15:21, Andreas Herrmann wrote:
> > On Mon, Aug 29, 2016 at 11:31:53AM +0530, Viresh Kumar wrote:
> > > I am _really_ worried about such hacks in drivers to negate the effect of
> > > a
>
On Wed, Sep 07, 2016 at 10:32:01AM +0530, Viresh Kumar wrote:
> On 01-09-16, 15:21, Andreas Herrmann wrote:
> > On Mon, Aug 29, 2016 at 11:31:53AM +0530, Viresh Kumar wrote:
> > > I am _really_ worried about such hacks in drivers to negate the effect of
> > > a
>
On Wed, Sep 07, 2016 at 10:32:01AM +0530, Viresh Kumar wrote:
> On 01-09-16, 15:21, Andreas Herrmann wrote:
---8<---
> > I started with the value return as "nominal latency" for PCC. This
> > was 30 ns on the test system and made things worse. I've tested
&g
On Wed, Sep 07, 2016 at 10:32:01AM +0530, Viresh Kumar wrote:
> On 01-09-16, 15:21, Andreas Herrmann wrote:
---8<---
> > I started with the value return as "nominal latency" for PCC. This
> > was 30 ns on the test system and made things worse. I've tested
&g
On Wed, Sep 07, 2016 at 10:32:01AM +0530, Viresh Kumar wrote:
> On 01-09-16, 15:21, Andreas Herrmann wrote:
> > On Mon, Aug 29, 2016 at 11:31:53AM +0530, Viresh Kumar wrote:
>
> > > I am _really_ worried about such hacks in drivers to negate the effect of
> > > a
On Wed, Sep 07, 2016 at 10:32:01AM +0530, Viresh Kumar wrote:
> On 01-09-16, 15:21, Andreas Herrmann wrote:
> > On Mon, Aug 29, 2016 at 11:31:53AM +0530, Viresh Kumar wrote:
>
> > > I am _really_ worried about such hacks in drivers to negate the effect of
> > > a
On Mon, Aug 29, 2016 at 11:31:53AM +0530, Viresh Kumar wrote:
> On 19-08-16, 14:21, Andreas Herrmann wrote:
> >
> > Commit 6393d6a102 (cpufreq: ondemand: Eliminate the deadband effect)
> > introduced a performance regression for systems using pcc-cpufreq and
On Mon, Aug 29, 2016 at 11:31:53AM +0530, Viresh Kumar wrote:
> On 19-08-16, 14:21, Andreas Herrmann wrote:
> >
> > Commit 6393d6a102 (cpufreq: ondemand: Eliminate the deadband effect)
> > introduced a performance regression for systems using pcc-cpufreq and
On Fri, Aug 19, 2016 at 02:18:14PM +0200, Andreas Herrmann wrote:
> Hello,
>
> I've observed performance degradation with different workloads on HP
> ProLiant systems that use pcc-cpufreq driver between older and more
> recent kernels. Bisection showed that commit 6393d6a102 (cpuf
On Fri, Aug 19, 2016 at 02:18:14PM +0200, Andreas Herrmann wrote:
> Hello,
>
> I've observed performance degradation with different workloads on HP
> ProLiant systems that use pcc-cpufreq driver between older and more
> recent kernels. Bisection showed that commit 6393d6a102 (cpuf
3148% 390.44 61.19 0:13.07 3453%
(HP ProLiant DL580 Gen8 system, 60 CPUs @ 2.80GHz)
Link: http://marc.info/?l=linux-pm=147160912625600
Signed-off-by: Andreas Herrmann <aherrm...@suse.com>
---
drivers/cpufreq/pcc-cpufreq.c | 20
1 file changed, 20 inse
3148% 390.44 61.19 0:13.07 3453%
(HP ProLiant DL580 Gen8 system, 60 CPUs @ 2.80GHz)
Link: http://marc.info/?l=linux-pm=147160912625600
Signed-off-by: Andreas Herrmann
---
drivers/cpufreq/pcc-cpufreq.c | 20
1 file changed, 20 insertions(+)
If this change is accepted
Hello,
I've observed performance degradation with different workloads on HP
ProLiant systems that use pcc-cpufreq driver between older and more
recent kernels. Bisection showed that commit 6393d6a102 (cpufreq:
ondemand: Eliminate the deadband effect) caused a significant
performance drop. This
Hello,
I've observed performance degradation with different workloads on HP
ProLiant systems that use pcc-cpufreq driver between older and more
recent kernels. Bisection showed that commit 6393d6a102 (cpufreq:
ondemand: Eliminate the deadband effect) caused a significant
performance drop. This
<jtane...@redhat.com>
CC: <sta...@vger.kernel.org> # 4.5+
Signed-off-by: Andreas Herrmann <aherrm...@suse.com>
---
Documentation/cpu-freq/pcc-cpufreq.txt | 4 ++--
drivers/cpufreq/pcc-cpufreq.c | 2 --
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/Do
um
CC: # 4.5+
Signed-off-by: Andreas Herrmann
---
Documentation/cpu-freq/pcc-cpufreq.txt | 4 ++--
drivers/cpufreq/pcc-cpufreq.c | 2 --
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/Documentation/cpu-freq/pcc-cpufreq.txt
b/Documentation/cpu-freq/pcc-cpufreq.txt
index 0
On Wed, Feb 10, 2016 at 08:47:15PM +0100, Markus Trippelsdorf wrote:
> On 2016.02.10 at 20:34 +0100, Andreas Herrmann wrote:
> > On Tue, Feb 09, 2016 at 06:41:56PM +0100, Markus Trippelsdorf wrote:
> > > > Recently Johannes sent a patch to enable scsi-mq per driver, see
> &
On Tue, Feb 09, 2016 at 06:41:56PM +0100, Markus Trippelsdorf wrote:
> On 2016.02.09 at 18:12 +0100, Andreas Herrmann wrote:
> > [CC-ing linux-block and linux-scsi and adding some comments]
> >
> > On Mon, Feb 01, 2016 at 11:43:40PM +0100, Andreas Herrmann wrote:
> &
On Tue, Feb 09, 2016 at 06:41:56PM +0100, Markus Trippelsdorf wrote:
> On 2016.02.09 at 18:12 +0100, Andreas Herrmann wrote:
> > [CC-ing linux-block and linux-scsi and adding some comments]
> >
> > On Mon, Feb 01, 2016 at 11:43:40PM +0100, Andreas Herrmann wrote:
> &
On Wed, Feb 10, 2016 at 08:47:15PM +0100, Markus Trippelsdorf wrote:
> On 2016.02.10 at 20:34 +0100, Andreas Herrmann wrote:
> > On Tue, Feb 09, 2016 at 06:41:56PM +0100, Markus Trippelsdorf wrote:
> > > > Recently Johannes sent a patch to enable scsi-mq per driver, see
> &
[CC-ing linux-block and linux-scsi and adding some comments]
On Mon, Feb 01, 2016 at 11:43:40PM +0100, Andreas Herrmann wrote:
> This introduces a new blk_mq hw attribute time_slice_us which allows
> to specify a time slice in usecs.
>
> Default value is 0 and implies no modificati
[CC-ing linux-block and linux-scsi and adding some comments]
On Mon, Feb 01, 2016 at 11:43:40PM +0100, Andreas Herrmann wrote:
> This introduces a new blk_mq hw attribute time_slice_us which allows
> to specify a time slice in usecs.
>
> Default value is 0 and implies no modificati
Following benchmark results for the patch using fio.
- kernel version 4.5.0-rc2-0001 (ie. with time-slice patch)
- Intel Core i7-3770S CPU @ 3.10GHz system, 4 cores, 8 threads/CPUs
- fio version as of 2.2.9-37-g0e1c4
- results were gathered iterating using rw and numjobs parameter, e.g.:
queue is
empty. Then the next software queue with pending requests is selected.
Signed-off-by: Andreas Herrmann
---
block/blk-mq-sysfs.c | 27 +++
block/blk-mq.c | 208 +
include/linux/blk-mq.h | 9 +++
3 files changed, 211 insertions
queue is
empty. Then the next software queue with pending requests is selected.
Signed-off-by: Andreas Herrmann <aherrm...@suse.com>
---
block/blk-mq-sysfs.c | 27 +++
block/blk-mq.c | 208 +
include/linux/blk-mq.h | 9 +++
3
Following benchmark results for the patch using fio.
- kernel version 4.5.0-rc2-0001 (ie. with time-slice patch)
- Intel Core i7-3770S CPU @ 3.10GHz system, 4 cores, 8 threads/CPUs
- fio version as of 2.2.9-37-g0e1c4
- results were gathered iterating using rw and numjobs parameter, e.g.:
On Wed, Nov 25, 2015 at 12:47:21PM -0700, Jens Axboe wrote:
> On 11/19/2015 05:02 AM, Andreas Herrmann wrote:
--8<--
> >The latter helped to improve performance for sequential reads and
> >writes. But it's not on a par with CFQ. Increasing the time slice is
> >suboptima
On Tue, Nov 24, 2015 at 09:19:32AM +0100, Christoph Hellwig wrote:
> Hi Andreas,
Hi Christoph,
> I don't understand the time slicing algorithm to well, but from the
> blk-mq integration perspective this looks nice, and anything that
> helps improving blk-mq for spinning rust is useful.
I'll put
On Wed, Nov 25, 2015 at 12:47:21PM -0700, Jens Axboe wrote:
> On 11/19/2015 05:02 AM, Andreas Herrmann wrote:
--8<--
> >The latter helped to improve performance for sequential reads and
> >writes. But it's not on a par with CFQ. Increasing the time slice is
> >suboptima
On Tue, Nov 24, 2015 at 09:19:32AM +0100, Christoph Hellwig wrote:
> Hi Andreas,
Hi Christoph,
> I don't understand the time slicing algorithm to well, but from the
> blk-mq integration perspective this looks nice, and anything that
> helps improving blk-mq for spinning rust is useful.
I'll put
6565656565
8 3280 2285 2188 2234 2403 86868686767
---
---
blk-mq: Introduce per sw queue time-slice
Signed-off-by: Andreas Herrmann
---
block/blk-mq-sysfs.c | 27 +
6565656565
8 3280 2285 2188 2234 2403 86868686767
---
---
blk-mq: Introduce per sw queue time-slice
Signed-off-by: Andreas Herrmann <aherrm...@suse.com>
---
block/blk-mq-sysfs
On Sat, Aug 29, 2015 at 09:33:54AM -0700, Guenter Roeck wrote:
> On Thu, Aug 27, 2015 at 04:07:46PM +0800, Huang Rui wrote:
> > Andreas Herrmann won't take the maintainer of fam15h_power driver. I
> > will take it and appreciate him for the great contributions on this
> > dr
On Sat, Aug 29, 2015 at 09:33:54AM -0700, Guenter Roeck wrote:
> On Thu, Aug 27, 2015 at 04:07:46PM +0800, Huang Rui wrote:
> > Andreas Herrmann won't take the maintainer of fam15h_power driver. I
> > will take it and appreciate him for the great contributions on this
> > dr
On Thu, May 22, 2014 at 03:26:45PM +0200, Ralf Baechle wrote:
> On Tue, May 20, 2014 at 06:16:14PM +0200, Paul Bolle wrote:
>
> > Three checks for CONFIG_CAVIUM_GDB were added in v2.6.29. But the
> > Kconfig symbol CAVIUM_GDB was never added to the tree. Remove these
> > checks.
> >
> > Also
On Thu, May 22, 2014 at 03:26:45PM +0200, Ralf Baechle wrote:
On Tue, May 20, 2014 at 06:16:14PM +0200, Paul Bolle wrote:
Three checks for CONFIG_CAVIUM_GDB were added in v2.6.29. But the
Kconfig symbol CAVIUM_GDB was never added to the tree. Remove these
checks.
Also remove the last
--
> Untested.
Removing this dead code shouldn't harm. I also did a quick test of a
kernel with your patch with an octeon system -- as expected no issues
observed. (So it's
Tested-by: Andreas Herrmann )
> A follow up might be to remove plat_smp_ops.cpus_done. All these
> callbacks are now (basi
.
Removing this dead code shouldn't harm. I also did a quick test of a
kernel with your patch with an octeon system -- as expected no issues
observed. (So it's
Tested-by: Andreas Herrmann andreas.herrm...@caviumnetworks.com)
A follow up might be to remove plat_smp_ops.cpus_done. All these
callbacks
On Mon, Apr 28, 2014 at 11:40:36PM +0200, Borislav Petkov wrote:
> On Mon, Apr 28, 2014 at 02:50:29PM -0600, Bjorn Helgaas wrote:
> > This I/O ECS thing seems likely to cause future problems. My
> > understanding (based on sec 2.8 of [1]) is that enable_pci_io_ecs()
> > and
On Mon, Apr 28, 2014 at 11:40:36PM +0200, Borislav Petkov wrote:
On Mon, Apr 28, 2014 at 02:50:29PM -0600, Bjorn Helgaas wrote:
This I/O ECS thing seems likely to cause future problems. My
understanding (based on sec 2.8 of [1]) is that enable_pci_io_ecs()
and pci_enable_pci_io_ecs() are
chle
> Cc: linux-m...@linux-mips.org
Tested-by: Andreas Herrmann
Thanks,
Andreas
> ---
> arch/mips/kernel/traps.c | 2 ++
> arch/mips/mm/c-octeon.c | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
> index
-mips.org
Tested-by: Andreas Herrmann andreas.herrm...@caviumnetworks.com
Thanks,
Andreas
---
arch/mips/kernel/traps.c | 2 ++
arch/mips/mm/c-octeon.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index 074e857..c51bd20 100644
cteon/setup.c:1073:7: error: assignment discards 'const'
qualifier from pointer target type [-Werror]
* Removed (now) obsolete extern declarations (for
__dtb_octeon_3xxx_end,
__dtb_octeon_68xx_end)]
Tested-by: Andreas Herrmann
Cc: Ralf Baechle
Cc: linux-m
/cavium-octeon/setup.c:1073:7: error: assignment discards 'const'
qualifier from pointer target type [-Werror]
* Removed (now) obsolete extern declarations (for
__dtb_octeon_3xxx_end,
__dtb_octeon_68xx_end)]
Tested-by: Andreas Herrmann andreas.herrm
On Thu, Nov 07, 2013 at 09:27:32AM +0100, Andreas Herrmann wrote:
> On Wed, Nov 06, 2013 at 04:38:10PM -0500, Christoph Lameter wrote:
> > On Wed, 6 Nov 2013, Andreas Herrmann wrote:
> >
> > > Would be nice, if your patch is pushed upstream asap.
> >
>
1 - 100 of 333 matches
Mail list logo
