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
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 mea
tialize 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
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: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: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: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 pe
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: Sel
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 kernels
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 num
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
> >
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 devices.
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
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
---
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
---
drivers/cpufreq/cpufreq_governor.h | 5 +
drivers/cpufreq/cpufreq_ondemand.c
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 639
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 messag
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,
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 test
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 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
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&m=147160912625600
Signed-off-by: Andreas Herrmann
---
drivers/cpufreq/pcc-cpufreq.c | 20
1 file changed, 20 insertions(+)
If this change is acce
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 pat
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:
> &
[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
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
> >subo
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
6363
7 3451 2711 2702 2565 2593 76565656565
8 3280 2285 2188 2234 2403 86868686767
-------
---
blk-mq: Introduce per sw queue time-slice
Signed-off-by: Andrea
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
> &g
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 remo
t; 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
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()
e
> 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
arch/mips/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
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.
> >
> >
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.
>
> Ok so this is a
>
> Tested-by: Andreas Herrmann
>
> I think?
Yes.
> BTW Calxeda
On Wed, Nov 06, 2013 at 09:34:29PM +0100, Andreas Herrmann wrote:
> On Wed, Nov 06, 2013 at 08:54:17PM +0100, Andreas Herrmann wrote:
> > On Wed, Nov 06, 2013 at 02:16:33PM -0500, Christoph Lameter wrote:
> > > On Wed, 6 Nov 2013, Andreas Herrmann wrote:
> > >
> &
On Wed, Nov 06, 2013 at 08:54:17PM +0100, Andreas Herrmann wrote:
> On Wed, Nov 06, 2013 at 02:16:33PM -0500, Christoph Lameter wrote:
> > On Wed, 6 Nov 2013, Andreas Herrmann wrote:
> >
> > > When I've used slub_debug kernel option (e.g.
> > > "slub_d
On Wed, Nov 06, 2013 at 02:16:33PM -0500, Christoph Lameter wrote:
> On Wed, 6 Nov 2013, Andreas Herrmann wrote:
>
> > When I've used slub_debug kernel option (e.g.
> > "slub_debug=,skbuff_fclone_cache" or similar) on a debug session I've
> > seen a pan
On Wed, Nov 06, 2013 at 02:16:33PM -0500, Christoph Lameter wrote:
> On Wed, 6 Nov 2013, Andreas Herrmann wrote:
>
> > When I've used slub_debug kernel option (e.g.
> > "slub_debug=,skbuff_fclone_cache" or similar) on a debug session I've
> > seen a pan
ut older kernels.
Cc: sta...@vger.kernel.org#3.10 and 3.11
Signed-off-by: Andreas Herrmann
---
mm/slub.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Patch is against v3.12-48-gbe408cd.
Regards,
Andreas
diff --git a/mm/slub.c b/mm/slub.c
index c3eb3d3..596c58a 100644
--- a/mm/slub.c
+
On Fri, Sep 27, 2013 at 12:13:22AM +0200, Borislav Petkov wrote:
> On Thu, Sep 26, 2013 at 04:54:32PM -0500, suravee.suthikulpa...@amd.com wrote:
> > From: Suravee Suthikulpanit
> >
> > On AMD family15h, applying microcode patch on the a core (core0)
> > would also affect the other core (core1) i
for sata_highbank. For the latter dma_coherent_mask could
be increased but due to the lack of DMA32 zone we need to adapt
arm_dma_limit in general.
Signed-off-by: Andreas Herrmann
---
arch/arm/mach-highbank/Kconfig|1 +
arch/arm/mach-highbank/highbank.c |3 +++
arch/arm/mm/dma-mapping.c
On Fri, May 31, 2013 at 01:26:49AM -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 30 May 2013, Jacob Shin wrote:
> > mkdir initrd
> > cd initrd
> > -mkdir kernel
> > -mkdir kernel/x86
> > -mkdir kernel/x86/microcode
> > -cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin
> > -find .|c
Hi Steven,
Hmm, the quirk looks quite familiar to me.
IMHO you should (re-?)read Documentation/SubmittingPatches.
(esp. no attachements, and btw one patch per mail)
Do you mind adding Joerg with his current (non-AMD) mail address on
CC? Otherwise it's impossible to get any comment from him.
An
On Thu, Nov 15, 2012 at 06:01:22PM -0500, Gene Heskett wrote:
> On Thursday 15 November 2012, Henrique de Moraes Holschuh wrote:
> >On Thu, 15 Nov 2012, Boris Ostrovsky wrote:
> >> Add valid patch size for family 16h processors
> >>
> >> Signed-off-by: Boris Ostrovsky
> >
> >Is this something tha
On Thu, Nov 15, 2012 at 04:26:28PM -0500, Boris Ostrovsky wrote:
>
>
> On 11/15/2012 03:45 PM, Henrique de Moraes Holschuh wrote:
> >On Thu, 15 Nov 2012, Boris Ostrovsky wrote:
> >>Add valid patch size for family 16h processors
> >>
> >>Signed-off-by: Boris Ostrovsky
> >
> >Is this something tha
On Thu, Nov 15, 2012 at 01:41:50PM -0500, Boris Ostrovsky wrote:
> Add valid patch size for family 16h processors
>
> Signed-off-by: Boris Ostrovsky
Acked-by: Andreas Herrmann
Thanks,
Andreas
> ---
> arch/x86/kernel/microcode_amd.c |4
> 1 file changed, 4 inser
Commit-ID: 27d3a8a26ada7660116fdd6830096008c063ee96
Gitweb: http://git.kernel.org/tip/27d3a8a26ada7660116fdd6830096008c063ee96
Author: Andreas Herrmann
AuthorDate: Fri, 19 Oct 2012 11:02:09 +0200
Committer: H. Peter Anvin
CommitDate: Tue, 13 Nov 2012 11:22:31 -0800
x86, cacheinfo
Commit-ID: 2e8458dfe4202df75543402c7343b8f94de4101e
Gitweb: http://git.kernel.org/tip/2e8458dfe4202df75543402c7343b8f94de4101e
Author: Andreas Herrmann
AuthorDate: Fri, 19 Oct 2012 11:00:49 +0200
Committer: H. Peter Anvin
CommitDate: Tue, 13 Nov 2012 11:22:30 -0800
x86, cacheinfo
Commit-ID: 04a1541828ea223169eb44a336bfad8ec0dfb46a
Gitweb: http://git.kernel.org/tip/04a1541828ea223169eb44a336bfad8ec0dfb46a
Author: Andreas Herrmann
AuthorDate: Fri, 19 Oct 2012 10:59:33 +0200
Committer: H. Peter Anvin
CommitDate: Tue, 13 Nov 2012 11:22:29 -0800
x86, cacheinfo
Commit-ID: 943482d07e926128eed0482b879736f912c429e4
Gitweb: http://git.kernel.org/tip/943482d07e926128eed0482b879736f912c429e4
Author: Andreas Herrmann
AuthorDate: Mon, 29 Oct 2012 18:51:38 +0100
Committer: Ingo Molnar
CommitDate: Tue, 30 Oct 2012 10:05:52 +0100
x86, microcode_amd
From: Robert Richter
Signed-off-by: Robert Richter
Signed-off-by: Andreas Herrmann
---
MAINTAINERS |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5a66583..5b8935b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5363,7 +5363,7 @@ S
Signed-off-by: Andreas Herrmann
---
drivers/cpufreq/powernow-k8.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/powernow-k8.c b/drivers/cpufreq/powernow-k8.c
index c16a3a5..e3ebb4f 100644
--- a/drivers/cpufreq/powernow-k8.c
+++ b/drivers/cpufreq/powernow
Signed-off-by: Andreas Herrmann
---
MAINTAINERS |4 ++--
arch/x86/kernel/microcode_amd.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index a4e8136..5a66583 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -534,9
Signed-off-by: Andreas Herrmann
---
Documentation/hwmon/fam15h_power |2 +-
MAINTAINERS |2 +-
drivers/hwmon/fam15h_power.c |4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/hwmon/fam15h_power b/Documentation/hwmon
Hi,
following patches are required to change Robert's, Boris' and my email
addresses as we won't have access to AMD email soon.
Regards,
Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info a
SW to add value of one to get result.
The corresponding bits on Intel are defined as "maximum number of threads
sharing this cache" (with a "plus 1" encoding).
Thus a different method to determine which cores are sharing a cache
level has to be used.
Signed-off-by: Andreas Herrm
Rely on CPUID 0x801d for cache information when AMD CPUID topology
extensions are available.
Signed-off-by: Andreas Herrmann
---
arch/x86/kernel/cpu/intel_cacheinfo.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c
b/arch
CPUID 0x801d works quite similar to Intels' CPUID function 4.
Use it to determine number of cache leafs.
Signed-off-by: Andreas Herrmann
---
arch/x86/include/asm/processor.h |2 +-
arch/x86/kernel/cpu/amd.c |7 +--
arch/x86/kernel/cpu/intel_cacheinfo.c |
Introduce cpu_has_topoext to check for AMD's CPUID topology extensions
support. It indicates support for
CPUID Fn8000_001D_EAX_x[N:0]-CPUID Fn8000_001E_EDX
See AMD's CPUID Specification, Publication # 25481
(as of Rev. 2.34 September 2010)
Signed-off-by: Andreas Herrmann
---
arch/x
Hi,
Following patches modify cachinfo code to make use of AMD's topology
extension CPUID functions. Thus (hopefully) we can avoid CPU specific
modifications whenever cache topology changes.
Please apply.
Thanks,
Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel
lways using work_on_cpu().
Cc: Tejun Heo
Cc: sta...@vger.kernel.org
Signed-off-by: Andreas Herrmann
---
drivers/cpufreq/powernow-k8.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/cpufreq/powernow-k8.c b/drivers/cpufreq/powernow-k8.c
index 129e80b..c16a3a5 1
Rafael,
Please ignore my patch. It was insufficiently tested -- sorry for this.
(powernowk8_target_fn might sleep).
Have to take a closer look how to avoid below issue.
Regards,
Andreas
On Tue, Oct 09, 2012 at 09:38:44PM +0200, Andreas Herrmann wrote:
>
>
using get_cpu/put_cpu in powernowk8_target().
Cc: Tejun Heo
Cc: sta...@vger.kernel.org
Signed-off-by: Andreas Herrmann
---
drivers/cpufreq/powernow-k8.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/cpufreq/powernow-k8.c b/drivers/cpufreq/powernow
Commit-ID: 36bf50d7697be18c6bfd0401e037df10bff1e573
Gitweb: http://git.kernel.org/tip/36bf50d7697be18c6bfd0401e037df10bff1e573
Author: Andreas Herrmann
AuthorDate: Tue, 31 Jul 2012 15:41:45 +0200
Committer: H. Peter Anvin
CommitDate: Wed, 22 Aug 2012 16:10:41 -0700
x86, microcode, AMD
Please apply.
Regards,
Andreas
---
x86_64: fix detection of CONSTANT_TSC bit for AMD CPUs
Set c->x86_power in early_identify_cpu. This ensures that
X86_FEATURE_CONSTANT_TSC can properly be set in early_init_amd.
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
diff --git a/arch/x8
On Fri, Nov 23, 2007 at 08:05:44AM +0200, Kirill A. Shutemov wrote:
> On [Fri, 23.11.2007 01:48], Thomas Gleixner wrote:
> > On Thu, 22 Nov 2007, Andrew Morton wrote:
> >
> > > On Thu, 22 Nov 2007 12:22:05 +0200 "Kirill A. Shutemov" <[EMAIL
> > > PROTECTED]> wrote:
> > >
> > > > On x86_64 'uname
<[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: "H. Peter Anvin" <[EMAIL PROTECTED]>
Acked-by: Sam Ravnborg <[EMAIL PROTECTED]>
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
arch/x86/Makefile |5 ++---
1 files changed, 2 insertions(
fbb83).
Some text was shamelessly stolen from one of Sam's patch
descriptions.
Comments are welcome.
Regards,
Andreas
--
Added documentation about kernel configuration and build for ARCH=x86.
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
arch/x
On Mon, Nov 19, 2007 at 11:41:29AM +0100, Sam Ravnborg wrote:
> On Mon, Nov 19, 2007 at 10:34:37AM +0100, Andreas Herrmann wrote:
> > On Sat, Nov 17, 2007 at 03:37:31PM +0100, Sam Ravnborg wrote:
> > >
> > > Note: This patch does not fix the uname -m issue - to do
c: "H. Peter Anvin" <[EMAIL PROTECTED]>
Cc: Sam Ravnborg <[EMAIL PROTECTED]>
Cc: Roman Zippel <[EMAIL PROTECTED]>
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
arch/x86/Makefile |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/
-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
drivers/video/aty/radeon_base.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c
index 1e32
are where the machine name came from.
Now that I know that (and shamelessly copying ideas from s390;-)
it is easy to fix. See attached patch.
Testing a crosscompiled 32-bit-kernel I now get
# uname -m
i686
on my K7.
Other tests will follow. But patch looks sane and should go mainline asap,
On Fri, Nov 16, 2007 at 12:14:46PM +0100, Andreas Herrmann wrote:
> BTW, is the x86 kernel build documented somewhere?
> At a first glance I didn't find anything suitable under Documentation/.
> Maybe some explanation (like the above) should be added there.
When the ARCH=x86 build
The new ARCH=x86 kernel build causes weired machine strings on 32-bit.
For a cross-compiled kernel I have
$ uname -m
x66_64
For a kernel natively built on a 32 bit machine I have
$ uname -m
x66
Looking at the sources, I think that utsname->machine was initial
Hi,
I have just some minor remarks wrt the commit message for
daa93fab824f2b8c35bd11670c7fab2f32b2de5f - 'x86: enable "make
ARCH=x86"'. (Based on my observations when testing the stuff on 64bit
and 32bit hosts with Linus' tree v2.6.24-rc2-640-g8c08634.)
For randconfig we have now the following be
_OK for CPU_ONLINE event.
Because CPU_ONLINE callback return value is always ignored.
[EMAIL PROTECTED]: avoid mce_remove_device() for not initialized device]
[EMAIL PROTECTED]: make mce_cpu_callback always return NOTIFY_OK]
Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]>
Signed-off-b
> >
> > - Avoid mce_remove_device() for the CPU that is not correctly initialized
> > by mce_create_device() failure.
> >
> > - make CPU_ONLINE callback always return NOTIFY_OK.
> > Because CPU_ONLINE callback return value is always ignored.
> >
> &
On Wed, Nov 07, 2007 at 12:04:51AM +0100, Sam Ravnborg wrote:
> This serie of patches unify the X86 Kconfig files.
> Next step is to enable use of "make ARCH=x86" and kill
> "make ARCH=i386/x86_64".
> But that will wait till tomorrow.
>
> The allmodconfig kernel is still building here.
> Testing /
> On Fri, 9 Nov 2007 09:47:02 +0100 SANGOI DINO LEONARDO <[EMAIL PROTECTED]>
> wrote:
> > Hi,
> >
> > My laptop (an HP nx6125) doesn't boot with kernels 2.6.24-rc1 and
> > 2.6.24.rc2.
> > It works fine with 2.6.23 and older.
> >
> > I seen this bug first while running fedora rawhide, so you c
t;
- Remove nested ifdef CONFIG_ACPI which required minor changes of the header.
- Remove unused function declaration for acpi_paddr_to_node. grep didn't
find a usage of that function.
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
include/acpi/acpi_drivers.h |3 ++
the corresponding PCI header file.
IMHO, this is where it really belongs to.
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
include/asm-x86/acpi_32.h |2 --
include/asm-x86/acpi_64.h |2 --
include/asm-x86/pci.h |1 +
3 files changed, 1 insertions(+), 4 deletions(-)
On Wed, Nov 07, 2007 at 03:35:43AM +0100, Andi Kleen wrote:
> On Wednesday 07 November 2007 02:12, Andreas Herrmann wrote:
>
> > In cases where not all CPUs are brought up during
> > boot (e.g. using maxcpus and additional_cpus parameters)
> > mce_cpu_callback now re
1 - 100 of 167 matches
Mail list logo
