* [Bug 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set
From: bugzilla-daemon @ 2020-04-23 1:36 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-199471-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=199471
--- Comment #21 from Erhard F. (erhard_f@mailbox.org) ---
(In reply to Dennis Clarke from comment #20)
>
> Possibly unrelated but there appears to be a small memory leak within
> windfarm_* somewhere given that I see traffic in kmemleak :
>
> [...]
>
> I will take a look into it and see what I can see.
Thanks, but probably there's no need to. ;)
There is already a patch floating around in the bug where I reported the
memleak originally: https://bugzilla.kernel.org/show_bug.cgi?id=206695
The patch just didn't went upstream yet.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH] i2c: powermac: Simplify reading the "reg" and "i2c-address" property
From: Erhard F. @ 2020-04-22 21:07 UTC (permalink / raw)
To: Wolfram Sang
Cc: Kate Stewart, linux-kernel, Richard Fontana, Paul Mackerras,
linux-i2c, Greg Kroah-Hartman, Thomas Gleixner, linuxppc-dev,
Aishwarya R
In-Reply-To: <20200421093712.GA1241@ninjato>
On Tue, 21 Apr 2020 11:37:13 +0200
Wolfram Sang <wsa@the-dreams.de> wrote:
> On Wed, Apr 15, 2020 at 06:49:14PM +0530, Aishwarya R wrote:
> > >> Use of_property_read_u32 to read the "reg" and "i2c-address" property
> > >> instead of using of_get_property to check the return values.
> > >>
> > >> Signed-off-by: Aishwarya R <aishwaryarj100@gmail.com>
> >
> > > This is quite a fragile driver. Have you tested it on HW?
> >
> > This change is not tested with the Hardware.
> > But of_property_read_u32 is better here than generic of_get_property.
> > This make sure that value read properly independent of system endianess.
>
> This driver is only used on PPC_BE. And it is *very* fragile. The gain
> is not enough for me to accept it without testing. Maybe Erhard (CCed)
> is interested. If not, you may find someone on the ppc lists.
>
I applied the patch on top of kernel 5.6.6 and tested it on a PowerMac G4 3,6 DP and a PowerMac G5 11,2. Both machines run without anything suspicious going on. dmesg | grep i2c looks the same with patch and without patch.
Tested-by: Erhard Furtner <erhard_f@mailbox.org>
^ permalink raw reply
* Re:Re: [PATCH v2,RESEND] misc: new driver sram_uapi for user level SRAM access
From: 王文虎 @ 2020-04-23 2:26 UTC (permalink / raw)
To: 王文虎
Cc: robh, arnd, gregkh, Randy Dunlap, linux-kernel, Scott Wood,
kernel, linuxppc-dev
In-Reply-To: <AEcAyQCMCDKzrJl2z8MdhKp5.3.1587602127200.Hmail.wenhu.wang@vivo.com>
>Hi, Scott, Greg,
>
>Thank you for your helpful comments.
>For that Greg mentioned that the patch (or patch series) via UIO should worked through,
>so I want to make it clear that if it would go upstream?(And if so, when? No push, just ask)
>
>Also I have been wondering how the patches with components in different subsystems
>go get upstream to the mainline? Like patch 1-3 are of linuxppc-dev, and patch 4 is of
>subsystem UIO, and if acceptable, how would you deal with them?
>
>Back to the devicetree thing, I make it detached from hardware compatibilities which belong
>to the hardware level driver and also used module parameter for of_id definition as dt-binding
>is not allowed for UIO now. So as I can see, things may go well and there is no harm to anything,
>I hope you(Scott) please take a re-consideration.
>
I mean I have get some new work done based on the comments of Arnd, Scott and Greg. Also a lot of tests done.
So it would be better to make it clear whether I shoud keep the work going or the UIO version is to be accepted
to go upstream recently in the future.
Thanks & regards,
Wenhu
>
>>On Sun, 2020-04-19 at 20:05 -0700, Wang Wenhu wrote:
>>> +static void sram_uapi_res_insert(struct sram_uapi *uapi,
>>> + struct sram_resource *res)
>>> +{
>>> + struct sram_resource *cur, *tmp;
>>> + struct list_head *head = &uapi->res_list;
>>> +
>>> + list_for_each_entry_safe(cur, tmp, head, list) {
>>> + if (&tmp->list != head &&
>>> + (cur->info.offset + cur->info.size + res->info.size <=
>>> + tmp->info.offset)) {
>>> + res->info.offset = cur->info.offset + cur->info.size;
>>> + res->parent = uapi;
>>> + list_add(&res->list, &cur->list);
>>> + return;
>>> + }
>>> + }
>>
>>We don't need yet another open coded allocator. If you really need to do this
>>then use include/linux/genalloc.h, but maybe keep it simple and just have one
>>allocaton per file descriptor so you don't need to manage fd offsets?
>>
>>> +static struct sram_resource *sram_uapi_find_res(struct sram_uapi *uapi,
>>> + __u32 offset)
>>> +{
>>> + struct sram_resource *res;
>>> +
>>> + list_for_each_entry(res, &uapi->res_list, list) {
>>> + if (res->info.offset == offset)
>>> + return res;
>>> + }
>>> +
>>> + return NULL;
>>> +}
>>
>>What if the allocation is more than one page, and the user mmaps starting
>>somewhere other than the first page?
>>
>>> + switch (cmd) {
>>> + case SRAM_UAPI_IOC_SET_SRAM_TYPE:
>>> + if (uapi->sa)
>>> + return -EEXIST;
>>> +
>>> + get_user(type, (const __u32 __user *)arg);
>>> + uapi->sa = get_sram_api_from_type(type);
>>> + if (uapi->sa)
>>> + ret = 0;
>>> + else
>>> + ret = -ENODEV;
>>> +
>>> + break;
>>> +
>>
>>Just expose one device per backing SRAM, especially if the user has any reason
>>to care about where the SRAM is coming from (correlating sysfs nodes is much
>>more expressive than some vague notion of "type").
>>
>>> + case SRAM_UAPI_IOC_ALLOC:
>>> + if (!uapi->sa)
>>> + return -EINVAL;
>>> +
>>> + res = kzalloc(sizeof(*res), GFP_KERNEL);
>>> + if (!res)
>>> + return -ENOMEM;
>>> +
>>> + size = copy_from_user((void *)&res->info,
>>> + (const void __user *)arg,
>>> + sizeof(res->info));
>>> + if (!PAGE_ALIGNED(res->info.size) || !res->info.size)
>>> + return -EINVAL;
>>
>>Missing EFAULT test (here and elsewhere), and res leaks on error.
>>
>>> +
>>> + res->virt = (void *)uapi->sa->sram_alloc(res->info.size,
>>> + &res->phys,
>>> + PAGE_SIZE);
>>
>>Do we really need multiple allocators, or could the backend be limited to just
>>adding regions to a generic allocator (with that allocator also serving in-
>>kernel users)?
>>
>>If sram_alloc is supposed to return a virtual address, why isn't that the
>>return type?
>>
>>> + if (!res->virt) {
>>> + kfree(res);
>>> + return -ENOMEM;
>>> + }
>>
>>ENOSPC might be more appropriate, as this isn't general-purpose RAM.
>>
>>> +
>>> + sram_uapi_res_insert(uapi, res);
>>> + size = copy_to_user((void __user *)arg,
>>> + (const void *)&res->info,
>>> + sizeof(res->info));
>>> +
>>> + ret = 0;
>>> + break;
>>> +
>>> + case SRAM_UAPI_IOC_FREE:
>>> + if (!uapi->sa)
>>> + return -EINVAL;
>>> +
>>> + size = copy_from_user((void *)&info, (const void __user *)arg,
>>> + sizeof(info));
>>> +
>>> + res = sram_uapi_res_delete(uapi, &info);
>>> + if (!res) {
>>> + pr_err("error no sram resource found\n");
>>> + return -EINVAL;
>>> + }
>>> +
>>> + uapi->sa->sram_free(res->virt);
>>> + kfree(res);
>>> +
>>> + ret = 0;
>>> + break;
>>
>>So you can just delete any arbitrary offset, even if you weren't the one that
>>allocated it? Even if this isn't meant for unprivileged use it seems error-
>>prone.
>>
>>> +
>>> + default:
>>> + pr_err("error no cmd not supported\n");
>>> + break;
>>> + }
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +static int sram_uapi_mmap(struct file *filp, struct vm_area_struct *vma)
>>> +{
>>> + struct sram_uapi *uapi = filp->private_data;
>>> + struct sram_resource *res;
>>> +
>>> + res = sram_uapi_find_res(uapi, vma->vm_pgoff);
>>> + if (!res)
>>> + return -EINVAL;
>>> +
>>> + if (vma->vm_end - vma->vm_start > res->info.size)
>>> + return -EINVAL;
>>> +
>>> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>>> +
>>> + return remap_pfn_range(vma, vma->vm_start,
>>> + res->phys >> PAGE_SHIFT,
>>> + vma->vm_end - vma->vm_start,
>>> + vma->vm_page_prot);
>>> +}
>>
>>Will noncached always be what's wanted here?
>>
>>-Scott
>>
>>
>
>
^ permalink raw reply
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Rich Felker @ 2020-04-23 2:36 UTC (permalink / raw)
To: Nicholas Piggin
Cc: libc-dev, libc-alpha, linuxppc-dev, Adhemerval Zanella, musl
In-Reply-To: <1587531042.1qvc287tsc.astroid@bobo.none>
On Wed, Apr 22, 2020 at 04:18:36PM +1000, Nicholas Piggin wrote:
> Yeah I had a bit of a play around with musl (which is very nice code I
> must say). The powerpc64 syscall asm is missing ctr clobber by the way.
> Fortunately adding it doesn't change code generation for me, but it
> should be fixed. glibc had the same bug at one point I think (probably
> due to syscall ABI documentation not existing -- something now lives in
> linux/Documentation/powerpc/syscall64-abi.rst).
Do you know anywhere I can read about the ctr issue, possibly the
relevant glibc bug report? I'm not particularly familiar with ppc
register file (at least I have to refamiliarize myself every time I
work on this stuff) so it'd be nice to understand what's
potentially-wrong now.
Rich
^ permalink raw reply
* Re: [PATCH 17/21] mm: free_area_init: allow defining max_zone_pfn in descending order
From: Baoquan He @ 2020-04-23 2:53 UTC (permalink / raw)
To: Mike Rapoport
Cc: Rich Felker, linux-ia64, linux-doc, Catalin Marinas,
Heiko Carstens, Michal Hocko, James E.J. Bottomley, Max Filippov,
Guo Ren, linux-csky, linux-parisc, sparclinux, linux-hexagon,
linux-riscv, Greg Ungerer, linux-arch, linux-s390, linux-snps-arc,
linux-c6x-dev, Brian Cain, Jonathan Corbet, linux-sh,
Helge Deller, x86, Russell King, Ley Foon Tan, Mike Rapoport,
Geert Uytterhoeven, linux-arm-kernel, Mark Salter, Matt Turner,
linux-mips, uclinux-h8-devel, linux-xtensa, linux-alpha, linux-um,
linux-m68k, Tony Luck, Greentime Hu, Paul Walmsley,
Stafford Horne, Guan Xuetao, Hoan Tran, Michal Simek,
Thomas Bogendoerfer, Yoshinori Sato, Nick Hu, linux-mm,
Vineet Gupta, linux-kernel, openrisc, Richard Weinberger,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200412194859.12663-18-rppt@kernel.org>
On 04/12/20 at 10:48pm, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
>
> Some architectures (e.g. ARC) have the ZONE_HIGHMEM zone below the
> ZONE_NORMAL. Allowing free_area_init() parse max_zone_pfn array even it is
> sorted in descending order allows using free_area_init() on such
> architectures.
>
> Add top -> down traversal of max_zone_pfn array in free_area_init() and use
> the latter in ARC node/zone initialization.
Or maybe leave ARC as is. The change in this patchset doesn't impact
ARC's handling about zone initialization, leaving it as is can reduce
the complication in implementation of free_area_init(), which is a
common function. So I personally don't see a strong motivation to have
this patch.
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
> arch/arc/mm/init.c | 36 +++++++-----------------------------
> mm/page_alloc.c | 24 +++++++++++++++++++-----
> 2 files changed, 26 insertions(+), 34 deletions(-)
>
> diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
> index 0920c969c466..41eb9be1653c 100644
> --- a/arch/arc/mm/init.c
> +++ b/arch/arc/mm/init.c
> @@ -63,11 +63,13 @@ void __init early_init_dt_add_memory_arch(u64 base, u64 size)
>
> low_mem_sz = size;
> in_use = 1;
> + memblock_add_node(base, size, 0);
> } else {
> #ifdef CONFIG_HIGHMEM
> high_mem_start = base;
> high_mem_sz = size;
> in_use = 1;
> + memblock_add_node(base, size, 1);
> #endif
> }
>
> @@ -83,8 +85,7 @@ void __init early_init_dt_add_memory_arch(u64 base, u64 size)
> */
> void __init setup_arch_memory(void)
> {
> - unsigned long zones_size[MAX_NR_ZONES];
> - unsigned long zones_holes[MAX_NR_ZONES];
> + unsigned long max_zone_pfn[MAX_NR_ZONES] = { 0 };
>
> init_mm.start_code = (unsigned long)_text;
> init_mm.end_code = (unsigned long)_etext;
> @@ -115,7 +116,6 @@ void __init setup_arch_memory(void)
> * the crash
> */
>
> - memblock_add_node(low_mem_start, low_mem_sz, 0);
> memblock_reserve(CONFIG_LINUX_LINK_BASE,
> __pa(_end) - CONFIG_LINUX_LINK_BASE);
>
> @@ -133,22 +133,7 @@ void __init setup_arch_memory(void)
> memblock_dump_all();
>
> /*----------------- node/zones setup --------------------------*/
> - memset(zones_size, 0, sizeof(zones_size));
> - memset(zones_holes, 0, sizeof(zones_holes));
> -
> - zones_size[ZONE_NORMAL] = max_low_pfn - min_low_pfn;
> - zones_holes[ZONE_NORMAL] = 0;
> -
> - /*
> - * We can't use the helper free_area_init(zones[]) because it uses
> - * PAGE_OFFSET to compute the @min_low_pfn which would be wrong
> - * when our kernel doesn't start at PAGE_OFFSET, i.e.
> - * PAGE_OFFSET != CONFIG_LINUX_RAM_BASE
> - */
> - free_area_init_node(0, /* node-id */
> - zones_size, /* num pages per zone */
> - min_low_pfn, /* first pfn of node */
> - zones_holes); /* holes */
> + max_zone_pfn[ZONE_NORMAL] = max_low_pfn;
>
> #ifdef CONFIG_HIGHMEM
> /*
> @@ -168,20 +153,13 @@ void __init setup_arch_memory(void)
> min_high_pfn = PFN_DOWN(high_mem_start);
> max_high_pfn = PFN_DOWN(high_mem_start + high_mem_sz);
>
> - zones_size[ZONE_NORMAL] = 0;
> - zones_holes[ZONE_NORMAL] = 0;
> -
> - zones_size[ZONE_HIGHMEM] = max_high_pfn - min_high_pfn;
> - zones_holes[ZONE_HIGHMEM] = 0;
> -
> - free_area_init_node(1, /* node-id */
> - zones_size, /* num pages per zone */
> - min_high_pfn, /* first pfn of node */
> - zones_holes); /* holes */
> + max_zone_pfn[ZONE_HIGHMEM] = max_high_pfn;
>
> high_memory = (void *)(min_high_pfn << PAGE_SHIFT);
> kmap_init();
> #endif
> +
> + free_area_init(max_zone_pfn);
> }
>
> /*
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 343d87b8697d..376434c7a78b 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -7429,7 +7429,8 @@ static void check_for_memory(pg_data_t *pgdat, int nid)
> void __init free_area_init(unsigned long *max_zone_pfn)
> {
> unsigned long start_pfn, end_pfn;
> - int i, nid;
> + int i, nid, zone;
> + bool descending = false;
>
> /* Record where the zone boundaries are */
> memset(arch_zone_lowest_possible_pfn, 0,
> @@ -7439,13 +7440,26 @@ void __init free_area_init(unsigned long *max_zone_pfn)
>
> start_pfn = find_min_pfn_with_active_regions();
>
> + /*
> + * Some architecturs, e.g. ARC may have ZONE_HIGHMEM below
> + * ZONE_NORMAL. For such cases we allow max_zone_pfn sorted in the
> + * descending order
> + */
> + if (MAX_NR_ZONES > 1 && max_zone_pfn[0] > max_zone_pfn[1])
> + descending = true;
> +
> for (i = 0; i < MAX_NR_ZONES; i++) {
> - if (i == ZONE_MOVABLE)
> + if (descending)
> + zone = MAX_NR_ZONES - i - 1;
> + else
> + zone = i;
> +
> + if (zone == ZONE_MOVABLE)
> continue;
>
> - end_pfn = max(max_zone_pfn[i], start_pfn);
> - arch_zone_lowest_possible_pfn[i] = start_pfn;
> - arch_zone_highest_possible_pfn[i] = end_pfn;
> + end_pfn = max(max_zone_pfn[zone], start_pfn);
> + arch_zone_lowest_possible_pfn[zone] = start_pfn;
> + arch_zone_highest_possible_pfn[zone] = end_pfn;
>
> start_pfn = end_pfn;
> }
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH v2 1/7] KVM: s390: clean up redundant 'kvm_run' parameters
From: Tianjia Zhang @ 2020-04-23 2:54 UTC (permalink / raw)
To: Cornelia Huck
Cc: wanpengli, kvm, david, heiko.carstens, peterx, linux-mips, hpa,
kvmarm, linux-s390, frankja, maz, joro, x86, borntraeger, mingo,
julien.thierry.kdev, thuth, gor, suzuki.poulose, kvm-ppc, bp,
tglx, linux-arm-kernel, jmattson, tsbogend, christoffer.dall,
sean.j.christopherson, linux-kernel, james.morse, pbonzini,
vkuznets, linuxppc-dev
In-Reply-To: <20200422154543.2efba3dd.cohuck@redhat.com>
On 2020/4/22 21:45, Cornelia Huck wrote:
> On Wed, 22 Apr 2020 20:58:04 +0800
> Tianjia Zhang <tianjia.zhang@linux.alibaba.com> wrote:
>
>> In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu'
>> structure. Earlier than historical reasons, many kvm-related function
>
> s/Earlier than/For/ ?
>
Yes, it should be replaced like this.
>> parameters retain the 'kvm_run' and 'kvm_vcpu' parameters at the same time.
>> This patch does a unified cleanup of these remaining redundant parameters.
>>
>> Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
>> ---
>> arch/s390/kvm/kvm-s390.c | 37 ++++++++++++++++++++++---------------
>> 1 file changed, 22 insertions(+), 15 deletions(-)
>>
>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>> index e335a7e5ead7..d7bb2e7a07ff 100644
>> --- a/arch/s390/kvm/kvm-s390.c
>> +++ b/arch/s390/kvm/kvm-s390.c
>> @@ -4176,8 +4176,9 @@ static int __vcpu_run(struct kvm_vcpu *vcpu)
>> return rc;
>> }
>>
>> -static void sync_regs_fmt2(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
>> +static void sync_regs_fmt2(struct kvm_vcpu *vcpu)
>> {
>> + struct kvm_run *kvm_run = vcpu->run;
>> struct runtime_instr_cb *riccb;
>> struct gs_cb *gscb;
>>
>> @@ -4235,7 +4236,7 @@ static void sync_regs_fmt2(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
>> }
>> if (vcpu->arch.gs_enabled) {
>> current->thread.gs_cb = (struct gs_cb *)
>> - &vcpu->run->s.regs.gscb;
>> + &kvm_run->s.regs.gscb;
>
> Not sure if these changes (vcpu->run-> => kvm_run->) are really worth
> it. (It seems they amount to at least as much as the changes advertised
> in the patch description.)
>
> Other opinions?
>
Why not replace `vcpu->run->` to `kvm_run->` ? If not, there will be
both styles of code, which is confusing. I will be confused and think
that this is something different.
Thanks,
Tianjia
>> restore_gs_cb(current->thread.gs_cb);
>> }
>> preempt_enable();
^ permalink raw reply
* Re: [PATCH 17/21] mm: free_area_init: allow defining max_zone_pfn in descending order
From: Baoquan He @ 2020-04-23 2:57 UTC (permalink / raw)
To: Mike Rapoport
Cc: Rich Felker, linux-ia64, linux-doc, Catalin Marinas,
Heiko Carstens, Michal Hocko, James E.J. Bottomley, Max Filippov,
Guo Ren, linux-csky, linux-parisc, sparclinux, linux-hexagon,
linux-riscv, Greg Ungerer, linux-arch, linux-s390, linux-snps-arc,
linux-c6x-dev, Brian Cain, Jonathan Corbet, linux-sh,
Helge Deller, x86, Russell King, Ley Foon Tan, Mike Rapoport,
Geert Uytterhoeven, linux-arm-kernel, Mark Salter, Matt Turner,
linux-mips, uclinux-h8-devel, linux-xtensa, linux-alpha, linux-um,
linux-m68k, Tony Luck, Greentime Hu, Paul Walmsley,
Stafford Horne, Guan Xuetao, Hoan Tran, Michal Simek,
Thomas Bogendoerfer, Yoshinori Sato, Nick Hu, linux-mm,
Vineet Gupta, linux-kernel, openrisc, Richard Weinberger,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200423025311.GZ4247@MiWiFi-R3L-srv>
On 04/23/20 at 10:53am, Baoquan He wrote:
> On 04/12/20 at 10:48pm, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt@linux.ibm.com>
> >
> > Some architectures (e.g. ARC) have the ZONE_HIGHMEM zone below the
> > ZONE_NORMAL. Allowing free_area_init() parse max_zone_pfn array even it is
> > sorted in descending order allows using free_area_init() on such
> > architectures.
> >
> > Add top -> down traversal of max_zone_pfn array in free_area_init() and use
> > the latter in ARC node/zone initialization.
>
> Or maybe leave ARC as is. The change in this patchset doesn't impact
> ARC's handling about zone initialization, leaving it as is can reduce
> the complication in implementation of free_area_init(), which is a
> common function. So I personally don't see a strong motivation to have
> this patch.
OK, seems this patch is prepared to simplify free_area_init_node(), so
take back what I said at above.
Then this looks necessary, even though it introduces special case into
common function free_area_init().
Reviewed-by: Baoquan He <bhe@redhat.com>
>
> >
> > Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> > ---
> > arch/arc/mm/init.c | 36 +++++++-----------------------------
> > mm/page_alloc.c | 24 +++++++++++++++++++-----
> > 2 files changed, 26 insertions(+), 34 deletions(-)
> >
> > diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
> > index 0920c969c466..41eb9be1653c 100644
> > --- a/arch/arc/mm/init.c
> > +++ b/arch/arc/mm/init.c
> > @@ -63,11 +63,13 @@ void __init early_init_dt_add_memory_arch(u64 base, u64 size)
> >
> > low_mem_sz = size;
> > in_use = 1;
> > + memblock_add_node(base, size, 0);
> > } else {
> > #ifdef CONFIG_HIGHMEM
> > high_mem_start = base;
> > high_mem_sz = size;
> > in_use = 1;
> > + memblock_add_node(base, size, 1);
> > #endif
> > }
> >
> > @@ -83,8 +85,7 @@ void __init early_init_dt_add_memory_arch(u64 base, u64 size)
> > */
> > void __init setup_arch_memory(void)
> > {
> > - unsigned long zones_size[MAX_NR_ZONES];
> > - unsigned long zones_holes[MAX_NR_ZONES];
> > + unsigned long max_zone_pfn[MAX_NR_ZONES] = { 0 };
> >
> > init_mm.start_code = (unsigned long)_text;
> > init_mm.end_code = (unsigned long)_etext;
> > @@ -115,7 +116,6 @@ void __init setup_arch_memory(void)
> > * the crash
> > */
> >
> > - memblock_add_node(low_mem_start, low_mem_sz, 0);
> > memblock_reserve(CONFIG_LINUX_LINK_BASE,
> > __pa(_end) - CONFIG_LINUX_LINK_BASE);
> >
> > @@ -133,22 +133,7 @@ void __init setup_arch_memory(void)
> > memblock_dump_all();
> >
> > /*----------------- node/zones setup --------------------------*/
> > - memset(zones_size, 0, sizeof(zones_size));
> > - memset(zones_holes, 0, sizeof(zones_holes));
> > -
> > - zones_size[ZONE_NORMAL] = max_low_pfn - min_low_pfn;
> > - zones_holes[ZONE_NORMAL] = 0;
> > -
> > - /*
> > - * We can't use the helper free_area_init(zones[]) because it uses
> > - * PAGE_OFFSET to compute the @min_low_pfn which would be wrong
> > - * when our kernel doesn't start at PAGE_OFFSET, i.e.
> > - * PAGE_OFFSET != CONFIG_LINUX_RAM_BASE
> > - */
> > - free_area_init_node(0, /* node-id */
> > - zones_size, /* num pages per zone */
> > - min_low_pfn, /* first pfn of node */
> > - zones_holes); /* holes */
> > + max_zone_pfn[ZONE_NORMAL] = max_low_pfn;
> >
> > #ifdef CONFIG_HIGHMEM
> > /*
> > @@ -168,20 +153,13 @@ void __init setup_arch_memory(void)
> > min_high_pfn = PFN_DOWN(high_mem_start);
> > max_high_pfn = PFN_DOWN(high_mem_start + high_mem_sz);
> >
> > - zones_size[ZONE_NORMAL] = 0;
> > - zones_holes[ZONE_NORMAL] = 0;
> > -
> > - zones_size[ZONE_HIGHMEM] = max_high_pfn - min_high_pfn;
> > - zones_holes[ZONE_HIGHMEM] = 0;
> > -
> > - free_area_init_node(1, /* node-id */
> > - zones_size, /* num pages per zone */
> > - min_high_pfn, /* first pfn of node */
> > - zones_holes); /* holes */
> > + max_zone_pfn[ZONE_HIGHMEM] = max_high_pfn;
> >
> > high_memory = (void *)(min_high_pfn << PAGE_SHIFT);
> > kmap_init();
> > #endif
> > +
> > + free_area_init(max_zone_pfn);
> > }
> >
> > /*
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 343d87b8697d..376434c7a78b 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -7429,7 +7429,8 @@ static void check_for_memory(pg_data_t *pgdat, int nid)
> > void __init free_area_init(unsigned long *max_zone_pfn)
> > {
> > unsigned long start_pfn, end_pfn;
> > - int i, nid;
> > + int i, nid, zone;
> > + bool descending = false;
> >
> > /* Record where the zone boundaries are */
> > memset(arch_zone_lowest_possible_pfn, 0,
> > @@ -7439,13 +7440,26 @@ void __init free_area_init(unsigned long *max_zone_pfn)
> >
> > start_pfn = find_min_pfn_with_active_regions();
> >
> > + /*
> > + * Some architecturs, e.g. ARC may have ZONE_HIGHMEM below
> > + * ZONE_NORMAL. For such cases we allow max_zone_pfn sorted in the
> > + * descending order
> > + */
> > + if (MAX_NR_ZONES > 1 && max_zone_pfn[0] > max_zone_pfn[1])
> > + descending = true;
> > +
> > for (i = 0; i < MAX_NR_ZONES; i++) {
> > - if (i == ZONE_MOVABLE)
> > + if (descending)
> > + zone = MAX_NR_ZONES - i - 1;
> > + else
> > + zone = i;
> > +
> > + if (zone == ZONE_MOVABLE)
> > continue;
> >
> > - end_pfn = max(max_zone_pfn[i], start_pfn);
> > - arch_zone_lowest_possible_pfn[i] = start_pfn;
> > - arch_zone_highest_possible_pfn[i] = end_pfn;
> > + end_pfn = max(max_zone_pfn[zone], start_pfn);
> > + arch_zone_lowest_possible_pfn[zone] = start_pfn;
> > + arch_zone_highest_possible_pfn[zone] = end_pfn;
> >
> > start_pfn = end_pfn;
> > }
> > --
> > 2.25.1
> >
^ permalink raw reply
* Re: [PATCH v2 1/7] KVM: s390: clean up redundant 'kvm_run' parameters
From: Tianjia Zhang @ 2020-04-23 3:01 UTC (permalink / raw)
To: Cornelia Huck, Christian Borntraeger
Cc: wanpengli, kvm, david, heiko.carstens, peterx, linux-mips, hpa,
kvmarm, linux-s390, frankja, maz, joro, x86, mingo,
julien.thierry.kdev, thuth, gor, suzuki.poulose, kvm-ppc, bp,
tglx, linux-arm-kernel, jmattson, tsbogend, christoffer.dall,
sean.j.christopherson, linux-kernel, james.morse, pbonzini,
vkuznets, linuxppc-dev
In-Reply-To: <20200422180403.03f60b0c.cohuck@redhat.com>
On 2020/4/23 0:04, Cornelia Huck wrote:
> On Wed, 22 Apr 2020 17:58:04 +0200
> Christian Borntraeger <borntraeger@de.ibm.com> wrote:
>
>> On 22.04.20 15:45, Cornelia Huck wrote:
>>> On Wed, 22 Apr 2020 20:58:04 +0800
>>> Tianjia Zhang <tianjia.zhang@linux.alibaba.com> wrote:
>>>
>>>> In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu'
>>>> structure. Earlier than historical reasons, many kvm-related function
>>>
>>> s/Earlier than/For/ ?
>>>
>>>> parameters retain the 'kvm_run' and 'kvm_vcpu' parameters at the same time.
>>>> This patch does a unified cleanup of these remaining redundant parameters.
>>>>
>>>> Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
>>>> ---
>>>> arch/s390/kvm/kvm-s390.c | 37 ++++++++++++++++++++++---------------
>>>> 1 file changed, 22 insertions(+), 15 deletions(-)
>>>>
>>>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>>>> index e335a7e5ead7..d7bb2e7a07ff 100644
>>>> --- a/arch/s390/kvm/kvm-s390.c
>>>> +++ b/arch/s390/kvm/kvm-s390.c
>>>> @@ -4176,8 +4176,9 @@ static int __vcpu_run(struct kvm_vcpu *vcpu)
>>>> return rc;
>>>> }
>>>>
>>>> -static void sync_regs_fmt2(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
>>>> +static void sync_regs_fmt2(struct kvm_vcpu *vcpu)
>>>> {
>>>> + struct kvm_run *kvm_run = vcpu->run;
>>>> struct runtime_instr_cb *riccb;
>>>> struct gs_cb *gscb;
>>>>
>>>> @@ -4235,7 +4236,7 @@ static void sync_regs_fmt2(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
>>>> }
>>>> if (vcpu->arch.gs_enabled) {
>>>> current->thread.gs_cb = (struct gs_cb *)
>>>> - &vcpu->run->s.regs.gscb;
>>>> + &kvm_run->s.regs.gscb;
>>>
>>> Not sure if these changes (vcpu->run-> => kvm_run->) are really worth
>>> it. (It seems they amount to at least as much as the changes advertised
>>> in the patch description.)
>>>
>>> Other opinions?
>>
>> Agreed. It feels kind of random. Maybe just do the first line (move kvm_run from the
>> function parameter list into the variable declaration)? Not sure if this is better.
>>
>
> There's more in this patch that I cut... but I think just moving
> kvm_run from the parameter list would be much less disruptive.
>
I think there are two kinds of code(`vcpu->run->` and `kvm_run->`), but
there will be more disruptive, not less.
Thanks,
Tianjia
^ permalink raw reply
* Re: [PATCH 18/21] mm: rename free_area_init_node() to free_area_init_memoryless_node()
From: Baoquan He @ 2020-04-23 3:14 UTC (permalink / raw)
To: Mike Rapoport
Cc: Rich Felker, linux-ia64, linux-doc, Catalin Marinas,
Heiko Carstens, Michal Hocko, James E.J. Bottomley, Max Filippov,
Guo Ren, linux-csky, linux-parisc, sparclinux, linux-hexagon,
linux-riscv, Greg Ungerer, linux-arch, linux-s390, linux-snps-arc,
linux-c6x-dev, Brian Cain, Jonathan Corbet, linux-sh,
Helge Deller, x86, Russell King, Ley Foon Tan, Mike Rapoport,
Geert Uytterhoeven, linux-arm-kernel, Mark Salter, Matt Turner,
linux-mips, uclinux-h8-devel, linux-xtensa, linux-alpha, linux-um,
linux-m68k, Tony Luck, Greentime Hu, Paul Walmsley,
Stafford Horne, Guan Xuetao, Hoan Tran, Michal Simek,
Thomas Bogendoerfer, Yoshinori Sato, Nick Hu, linux-mm,
Vineet Gupta, linux-kernel, openrisc, Richard Weinberger,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200412194859.12663-19-rppt@kernel.org>
On 04/12/20 at 10:48pm, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
>
> The free_area_init_node() is only used by x86 to initialize a memory-less
> nodes.
> Make its name reflect this and drop all the function parameters except node
> ID as they are anyway zero.
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
> arch/x86/mm/numa.c | 5 +----
> include/linux/mm.h | 9 +++------
> mm/page_alloc.c | 7 ++-----
> 3 files changed, 6 insertions(+), 15 deletions(-)
>
> diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> index fe024b2ac796..8ee952038c80 100644
> --- a/arch/x86/mm/numa.c
> +++ b/arch/x86/mm/numa.c
> @@ -737,12 +737,9 @@ void __init x86_numa_init(void)
>
> static void __init init_memory_less_node(int nid)
> {
> - unsigned long zones_size[MAX_NR_ZONES] = {0};
> - unsigned long zholes_size[MAX_NR_ZONES] = {0};
> -
> /* Allocate and initialize node data. Memory-less node is now online.*/
> alloc_node_data(nid);
> - free_area_init_node(nid, zones_size, 0, zholes_size);
> + free_area_init_memoryless_node(nid);
>
> /*
> * All zonelists will be built later in start_kernel() after per cpu
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 1c2ecb42e043..27660f6cf26e 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2272,8 +2272,7 @@ static inline spinlock_t *pud_lock(struct mm_struct *mm, pud_t *pud)
> }
>
> extern void __init pagecache_init(void);
> -extern void __init free_area_init_node(int nid, unsigned long * zones_size,
> - unsigned long zone_start_pfn, unsigned long *zholes_size);
> +extern void __init free_area_init_memoryless_node(int nid);
> extern void free_initmem(void);
>
> /*
> @@ -2345,10 +2344,8 @@ static inline unsigned long get_num_physpages(void)
>
> /*
> * Using memblock node mappings, an architecture may initialise its
> - * zones, allocate the backing mem_map and account for memory holes in a more
> - * architecture independent manner. This is a substitute for creating the
> - * zone_sizes[] and zholes_size[] arrays and passing them to
> - * free_area_init_node()
> + * zones, allocate the backing mem_map and account for memory holes in an
> + * architecture independent manner.
> *
> * An architecture is expected to register range of page frames backed by
> * physical memory with memblock_add[_node]() before calling
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 376434c7a78b..e46232ec4849 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6979,12 +6979,9 @@ static void __init __free_area_init_node(int nid, unsigned long *zones_size,
> free_area_init_core(pgdat);
> }
>
> -void __init free_area_init_node(int nid, unsigned long *zones_size,
> - unsigned long node_start_pfn,
> - unsigned long *zholes_size)
> +void __init free_area_init_memoryless_node(int nid)
> {
> - __free_area_init_node(nid, zones_size, node_start_pfn, zholes_size,
> - true);
> + __free_area_init_node(nid, NULL, 0, NULL, false);
Can we move free_area_init_memoryless_node() definition into
arch/x86/mm/numa.c since there's only one caller there?
And I am also wondering if adding a wrapper
free_area_init_memoryless_node() is necessary if it's only called the
function free_area_init_node().
> }
>
> #if !defined(CONFIG_FLAT_NODE_MEM_MAP)
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH v2 1/7] KVM: s390: clean up redundant 'kvm_run' parameters
From: Tianjia Zhang @ 2020-04-23 3:14 UTC (permalink / raw)
To: Christian Borntraeger, Cornelia Huck
Cc: wanpengli, kvm, david, heiko.carstens, peterx, linux-mips, hpa,
kvmarm, linux-s390, frankja, maz, joro, x86, mingo,
julien.thierry.kdev, thuth, gor, suzuki.poulose, kvm-ppc, bp,
tglx, linux-arm-kernel, jmattson, tsbogend, christoffer.dall,
sean.j.christopherson, linux-kernel, james.morse, pbonzini,
vkuznets, linuxppc-dev
In-Reply-To: <dc5e0fa3-558b-d606-bda9-ed281cf9e9ae@de.ibm.com>
On 2020/4/22 23:58, Christian Borntraeger wrote:
>
>
> On 22.04.20 15:45, Cornelia Huck wrote:
>> On Wed, 22 Apr 2020 20:58:04 +0800
>> Tianjia Zhang <tianjia.zhang@linux.alibaba.com> wrote:
>>
>>> In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu'
>>> structure. Earlier than historical reasons, many kvm-related function
>>
>> s/Earlier than/For/ ?
>>
>>> parameters retain the 'kvm_run' and 'kvm_vcpu' parameters at the same time.
>>> This patch does a unified cleanup of these remaining redundant parameters.
>>>
>>> Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
>>> ---
>>> arch/s390/kvm/kvm-s390.c | 37 ++++++++++++++++++++++---------------
>>> 1 file changed, 22 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>>> index e335a7e5ead7..d7bb2e7a07ff 100644
>>> --- a/arch/s390/kvm/kvm-s390.c
>>> +++ b/arch/s390/kvm/kvm-s390.c
>>> @@ -4176,8 +4176,9 @@ static int __vcpu_run(struct kvm_vcpu *vcpu)
>>> return rc;
>>> }
>>>
>>> -static void sync_regs_fmt2(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
>>> +static void sync_regs_fmt2(struct kvm_vcpu *vcpu)
>>> {
>>> + struct kvm_run *kvm_run = vcpu->run;
>>> struct runtime_instr_cb *riccb;
>>> struct gs_cb *gscb;
>>>
>>> @@ -4235,7 +4236,7 @@ static void sync_regs_fmt2(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
>>> }
>>> if (vcpu->arch.gs_enabled) {
>>> current->thread.gs_cb = (struct gs_cb *)
>>> - &vcpu->run->s.regs.gscb;
>>> + &kvm_run->s.regs.gscb;
>>
>> Not sure if these changes (vcpu->run-> => kvm_run->) are really worth
>> it. (It seems they amount to at least as much as the changes advertised
>> in the patch description.)
>>
>> Other opinions?
>
> Agreed. It feels kind of random. Maybe just do the first line (move kvm_run from the
> function parameter list into the variable declaration)? Not sure if this is better.
>
Why not, `kvm_run` is equivalent to `vcpu->run`, which is also part of
the cleanup, or do you mean to put this change in another patch?
Thanks,
Tianjia
^ permalink raw reply
* [PATCH 1/2] powerpc: dt_cpu_ftrs: Set current thread fscr bits
From: Alistair Popple @ 2020-04-23 4:40 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mikey, oohall, npiggin, Alistair Popple
Setting the FSCR bit directly in the SPR only sets it for the initial
boot and early init of the kernel. When the init process is started it
gets copied from the current thread_struct which does not reflect any
changes made during CPU feature detection. This patch ensures the
current thread_struct state is updated to match FSCR after feature
detection is complete.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
---
arch/powerpc/kernel/dt_cpu_ftrs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c b/arch/powerpc/kernel/dt_cpu_ftrs.c
index 36bc0d5c4f3a..dede8f0b678f 100644
--- a/arch/powerpc/kernel/dt_cpu_ftrs.c
+++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
@@ -169,6 +169,7 @@ static int __init feat_try_enable_unknown(struct dt_cpu_feature *f)
u64 fscr = mfspr(SPRN_FSCR);
fscr |= 1UL << f->fscr_bit_nr;
mtspr(SPRN_FSCR, fscr);
+ current->thread.fscr |= 1UL << f->fscr_bit_nr;
} else {
/* Does not have a known recipe */
return 0;
@@ -204,6 +205,7 @@ static int __init feat_enable(struct dt_cpu_feature *f)
u64 fscr = mfspr(SPRN_FSCR);
fscr |= 1UL << f->fscr_bit_nr;
mtspr(SPRN_FSCR, fscr);
+ current->thread.fscr |= 1UL << f->fscr_bit_nr;
}
}
--
2.20.1
^ permalink raw reply related
* [PATCH 2/2] powerpc: Enable Prefixed Instructions
From: Alistair Popple @ 2020-04-23 4:40 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mikey, oohall, npiggin, Alistair Popple
In-Reply-To: <20200423044057.5517-1-alistair@popple.id.au>
Prefix instructions have their own FSCR bit which needs to enabled via
a CPU feature. The kernel will save the FSCR for problem state but it
needs to be enabled initially.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
---
arch/powerpc/kernel/dt_cpu_ftrs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c b/arch/powerpc/kernel/dt_cpu_ftrs.c
index dede8f0b678f..e4caa4456869 100644
--- a/arch/powerpc/kernel/dt_cpu_ftrs.c
+++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
@@ -627,6 +627,7 @@ static struct dt_cpu_feature_match __initdata
{"vector-binary128", feat_enable, 0},
{"vector-binary16", feat_enable, 0},
{"wait-v3", feat_enable, 0},
+ {"prefix-instructions", feat_enable, 0},
};
static bool __initdata using_dt_cpu_ftrs;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH V3 0/3] arm64: Enable vmemmap mapping from device memory
From: Anshuman Khandual @ 2020-04-23 5:10 UTC (permalink / raw)
To: linux-mm
Cc: Mark Rutland, Michal Hocko, Thomas Gleixner, David Hildenbrand,
Peter Zijlstra, Catalin Marinas, Dave Hansen, Paul Mackerras,
linux-ia64, linux-riscv, Will Deacon, jgg, aneesh.kumar, x86,
Matthew Wilcox (Oracle), Mike Rapoport, Ingo Molnar, Fenghua Yu,
rcampbell, Pavel Tatashin, jglisse, Andy Lutomirski,
Paul Walmsley, dan.j.williams, linux-arm-kernel, Tony Luck,
linuxppc-dev, linux-kernel, Palmer Dabbelt, Andrew Morton,
robin.murphy, Kirill A. Shutemov
In-Reply-To: <1585631387-18819-1-git-send-email-anshuman.khandual@arm.com>
On 03/31/2020 10:39 AM, Anshuman Khandual wrote:
> This series enables vmemmap backing memory allocation from device memory
> ranges on arm64. But before that, it enables vmemmap_populate_basepages()
> and vmemmap_alloc_block_buf() to accommodate struct vmem_altmap based
> alocation requests.
>
> This series applies after latest (v14) arm64 memory hot remove series
> (https://lkml.org/lkml/2020/3/3/1746) on Linux 5.6.
>
> Pending Question:
>
> altmap_alloc_block_buf() does not have any other remaining users in the
> tree after this change. Should it be converted into a static function and
> it's declaration be dropped from the header (include/linux/mm.h). Avoided
> doing so because I was not sure if there are any off-tree users or not.
>
> Changes in V3:
>
> - Dropped comment from free_hotplug_page_range() per Robin
> - Modified comment in unmap_hotplug_range() per Robin
> - Enabled altmap support in vmemmap_alloc_block_buf() per Robin
Just a gentle ping. Any updates on this series ? In particular, is there
any comments or suggestions or concerns with respect to the first two
patches here that change the core MM and relevant call sites on some
platforms. Thank you.
- Anshuman
^ permalink raw reply
* Re: [PATCH, RESEND, 1/3] selftests/powerpc: Use write_pmc instead of count_pmc to reset PMCs on ebb tests
From: Rashmica Gupta @ 2020-04-23 5:45 UTC (permalink / raw)
To: Desnes A. Nunes do Rosario, linuxppc-dev; +Cc: shuah, gromero
In-Reply-To: <20200408223543.21168-2-desnesn@linux.ibm.com>
On Wed, 2020-04-08 at 19:35 -0300, Desnes A. Nunes do Rosario wrote:
> By using count_pmc() to reset PMCs instead of write_pmc(), an extra
> count
> is performed on ebb_state.stats.pmc_count[PMC_INDEX(pmc)]. This extra
> pmc_count can occasionally invalidate results, such as the ones from
> cycles_test shown hereafter. The ebb_check_count() failed with an
> above
> the upper limit error due to the extra ebb_state.stats.pmc_count.
>
> Furthermore, this extra count is also indicated by extra PMC1
> trace_log on
> the output of the cycle test (as well as on pmc56_overflow_test):
>
> ==========
> ...
> [21]: counter = 8
> [22]: register SPRN_MMCR0 = 0x0000000080000080
> [23]: register SPRN_PMC1 = 0x0000000080000004
> [24]: counter = 9
> [25]: register SPRN_MMCR0 = 0x0000000080000080
> [26]: register SPRN_PMC1 = 0x0000000080000004
> [27]: counter = 10
> [28]: register SPRN_MMCR0 = 0x0000000080000080
> [29]: register SPRN_PMC1 = 0x0000000080000004
> > > [30]: register SPRN_PMC1 = 0x000000004000051e
> PMC1 count (0x280000546) above upper limit 0x2800003e8 (+0x15e)
> [FAIL] Test FAILED on line 52
> failure: cycles
> ==========
>
> [desnesn: reflow of original comment]
> Signed-off-by: Desnes A. Nunes do Rosario <desnesn@linux.ibm.com>
Reviewed and Tested-by: Rashmica Gupta <rashmica.g@gmail.com>
> ---
> .../powerpc/pmu/ebb/back_to_back_ebbs_test.c | 2 +-
> .../testing/selftests/powerpc/pmu/ebb/cycles_test.c | 2 +-
> .../powerpc/pmu/ebb/cycles_with_freeze_test.c | 2 +-
> .../powerpc/pmu/ebb/cycles_with_mmcr2_test.c | 2 +-
> tools/testing/selftests/powerpc/pmu/ebb/ebb.c | 2 +-
> .../powerpc/pmu/ebb/ebb_on_willing_child_test.c | 2 +-
> .../selftests/powerpc/pmu/ebb/lost_exception_test.c | 2 +-
> .../selftests/powerpc/pmu/ebb/multi_counter_test.c | 12 ++++++--
> ----
> .../selftests/powerpc/pmu/ebb/multi_ebb_procs_test.c | 2 +-
> .../selftests/powerpc/pmu/ebb/pmae_handling_test.c | 2 +-
> .../selftests/powerpc/pmu/ebb/pmc56_overflow_test.c | 2 +-
> 11 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git
> a/tools/testing/selftests/powerpc/pmu/ebb/back_to_back_ebbs_test.c
> b/tools/testing/selftests/powerpc/pmu/ebb/back_to_back_ebbs_test.c
> index a2d7b0e3dca9..f133ab425f10 100644
> ---
> a/tools/testing/selftests/powerpc/pmu/ebb/back_to_back_ebbs_test.c
> +++
> b/tools/testing/selftests/powerpc/pmu/ebb/back_to_back_ebbs_test.c
> @@ -91,7 +91,7 @@ int back_to_back_ebbs(void)
> ebb_global_disable();
> ebb_freeze_pmcs();
>
> - count_pmc(1, sample_period);
> + write_pmc(1, pmc_sample_period(sample_period));
>
> dump_ebb_state();
>
> diff --git a/tools/testing/selftests/powerpc/pmu/ebb/cycles_test.c
> b/tools/testing/selftests/powerpc/pmu/ebb/cycles_test.c
> index bc893813483e..14a399a64729 100644
> --- a/tools/testing/selftests/powerpc/pmu/ebb/cycles_test.c
> +++ b/tools/testing/selftests/powerpc/pmu/ebb/cycles_test.c
> @@ -42,7 +42,7 @@ int cycles(void)
> ebb_global_disable();
> ebb_freeze_pmcs();
>
> - count_pmc(1, sample_period);
> + write_pmc(1, pmc_sample_period(sample_period));
>
> dump_ebb_state();
>
> diff --git
> a/tools/testing/selftests/powerpc/pmu/ebb/cycles_with_freeze_test.c
> b/tools/testing/selftests/powerpc/pmu/ebb/cycles_with_freeze_test.c
> index dcd351d20328..0f2089f6f82c 100644
> ---
> a/tools/testing/selftests/powerpc/pmu/ebb/cycles_with_freeze_test.c
> +++
> b/tools/testing/selftests/powerpc/pmu/ebb/cycles_with_freeze_test.c
> @@ -99,7 +99,7 @@ int cycles_with_freeze(void)
> ebb_global_disable();
> ebb_freeze_pmcs();
>
> - count_pmc(1, sample_period);
> + write_pmc(1, pmc_sample_period(sample_period));
>
> dump_ebb_state();
>
> diff --git
> a/tools/testing/selftests/powerpc/pmu/ebb/cycles_with_mmcr2_test.c
> b/tools/testing/selftests/powerpc/pmu/ebb/cycles_with_mmcr2_test.c
> index 94c99c12c0f2..a8f3bee04cd8 100644
> ---
> a/tools/testing/selftests/powerpc/pmu/ebb/cycles_with_mmcr2_test.c
> +++
> b/tools/testing/selftests/powerpc/pmu/ebb/cycles_with_mmcr2_test.c
> @@ -71,7 +71,7 @@ int cycles_with_mmcr2(void)
> ebb_global_disable();
> ebb_freeze_pmcs();
>
> - count_pmc(1, sample_period);
> + write_pmc(1, pmc_sample_period(sample_period));
>
> dump_ebb_state();
>
> diff --git a/tools/testing/selftests/powerpc/pmu/ebb/ebb.c
> b/tools/testing/selftests/powerpc/pmu/ebb/ebb.c
> index dfbc5c3ad52d..bf6f25dfcf7b 100644
> --- a/tools/testing/selftests/powerpc/pmu/ebb/ebb.c
> +++ b/tools/testing/selftests/powerpc/pmu/ebb/ebb.c
> @@ -396,7 +396,7 @@ int ebb_child(union pipe read_pipe, union pipe
> write_pipe)
> ebb_global_disable();
> ebb_freeze_pmcs();
>
> - count_pmc(1, sample_period);
> + write_pmc(1, pmc_sample_period(sample_period));
>
> dump_ebb_state();
>
> diff --git
> a/tools/testing/selftests/powerpc/pmu/ebb/ebb_on_willing_child_test.c
> b/tools/testing/selftests/powerpc/pmu/ebb/ebb_on_willing_child_test.c
> index ca2f7d729155..513812cdcca1 100644
> ---
> a/tools/testing/selftests/powerpc/pmu/ebb/ebb_on_willing_child_test.c
> +++
> b/tools/testing/selftests/powerpc/pmu/ebb/ebb_on_willing_child_test.c
> @@ -38,7 +38,7 @@ static int victim_child(union pipe read_pipe, union
> pipe write_pipe)
> ebb_global_disable();
> ebb_freeze_pmcs();
>
> - count_pmc(1, sample_period);
> + write_pmc(1, pmc_sample_period(sample_period));
>
> dump_ebb_state();
>
> diff --git
> a/tools/testing/selftests/powerpc/pmu/ebb/lost_exception_test.c
> b/tools/testing/selftests/powerpc/pmu/ebb/lost_exception_test.c
> index ac3e6e182614..5979606c41dc 100644
> --- a/tools/testing/selftests/powerpc/pmu/ebb/lost_exception_test.c
> +++ b/tools/testing/selftests/powerpc/pmu/ebb/lost_exception_test.c
> @@ -75,7 +75,7 @@ static int test_body(void)
> ebb_freeze_pmcs();
> ebb_global_disable();
>
> - count_pmc(4, sample_period);
> + write_pmc(4, pmc_sample_period(sample_period));
> mtspr(SPRN_PMC4, 0xdead);
>
> dump_summary_ebb_state();
> diff --git
> a/tools/testing/selftests/powerpc/pmu/ebb/multi_counter_test.c
> b/tools/testing/selftests/powerpc/pmu/ebb/multi_counter_test.c
> index b8242e9d97d2..227827b665d5 100644
> --- a/tools/testing/selftests/powerpc/pmu/ebb/multi_counter_test.c
> +++ b/tools/testing/selftests/powerpc/pmu/ebb/multi_counter_test.c
> @@ -70,12 +70,12 @@ int multi_counter(void)
> ebb_global_disable();
> ebb_freeze_pmcs();
>
> - count_pmc(1, sample_period);
> - count_pmc(2, sample_period);
> - count_pmc(3, sample_period);
> - count_pmc(4, sample_period);
> - count_pmc(5, sample_period);
> - count_pmc(6, sample_period);
> + write_pmc(1, pmc_sample_period(sample_period));
> + write_pmc(2, pmc_sample_period(sample_period));
> + write_pmc(3, pmc_sample_period(sample_period));
> + write_pmc(4, pmc_sample_period(sample_period));
> + write_pmc(5, pmc_sample_period(sample_period));
> + write_pmc(6, pmc_sample_period(sample_period));
>
> dump_ebb_state();
>
> diff --git
> a/tools/testing/selftests/powerpc/pmu/ebb/multi_ebb_procs_test.c
> b/tools/testing/selftests/powerpc/pmu/ebb/multi_ebb_procs_test.c
> index a05c0e18ded6..ade70bed0499 100644
> --- a/tools/testing/selftests/powerpc/pmu/ebb/multi_ebb_procs_test.c
> +++ b/tools/testing/selftests/powerpc/pmu/ebb/multi_ebb_procs_test.c
> @@ -61,7 +61,7 @@ static int cycles_child(void)
> ebb_global_disable();
> ebb_freeze_pmcs();
>
> - count_pmc(1, sample_period);
> + write_pmc(1, pmc_sample_period(sample_period));
>
> dump_summary_ebb_state();
>
> diff --git
> a/tools/testing/selftests/powerpc/pmu/ebb/pmae_handling_test.c
> b/tools/testing/selftests/powerpc/pmu/ebb/pmae_handling_test.c
> index 153ebc92234f..7b4bf4ed12cb 100644
> --- a/tools/testing/selftests/powerpc/pmu/ebb/pmae_handling_test.c
> +++ b/tools/testing/selftests/powerpc/pmu/ebb/pmae_handling_test.c
> @@ -82,7 +82,7 @@ static int test_body(void)
> ebb_global_disable();
> ebb_freeze_pmcs();
>
> - count_pmc(1, sample_period);
> + write_pmc(1, pmc_sample_period(sample_period));
>
> dump_ebb_state();
>
> diff --git
> a/tools/testing/selftests/powerpc/pmu/ebb/pmc56_overflow_test.c
> b/tools/testing/selftests/powerpc/pmu/ebb/pmc56_overflow_test.c
> index eadad75ed7e6..bb55af71404d 100644
> --- a/tools/testing/selftests/powerpc/pmu/ebb/pmc56_overflow_test.c
> +++ b/tools/testing/selftests/powerpc/pmu/ebb/pmc56_overflow_test.c
> @@ -76,7 +76,7 @@ int pmc56_overflow(void)
> ebb_global_disable();
> ebb_freeze_pmcs();
>
> - count_pmc(2, sample_period);
> + write_pmc(2, pmc_sample_period(sample_period));
>
> dump_ebb_state();
>
^ permalink raw reply
* Re: [PATCH, RESEND, 2/3] selftests/powerpc: enable performance alerts when freezing counters on cycles_with_freeze_test selftest
From: Rashmica Gupta @ 2020-04-23 5:47 UTC (permalink / raw)
To: Desnes A. Nunes do Rosario, linuxppc-dev; +Cc: shuah, gromero
In-Reply-To: <20200408223543.21168-3-desnesn@linux.ibm.com>
On Wed, 2020-04-08 at 19:35 -0300, Desnes A. Nunes do Rosario wrote:
> From: Gustavo Romero <gromero@linux.ibm.com>
>
> When disabling freezing counters by setting MMCR0 FC bit to 0, the
> MMCR0
> PMAE bit must also be enabled if a Performance Monitor Alert (and the
> cor-
> responding Performance Monitor Interrupt) is still desired to be
> received
> when an enabled condition or event occurs.
>
> This is the case of the cycles_with_freeze_test selftest, since the
> test
> disables the MMCR0 PMAE due to the usage of PMU to trigger EBBs. This
> can
> make the test loop up to the point of being killed by the test
> harness
> timeout (2500 ms), since no other ebb event will happen because the
> MMCR0
> PMAE bit is disabled, and thus, no more increments to ebb_count
> occur.
>
> Fixes: 3752e453f6bafd7 ("selftests/powerpc: Add tests of PMU EBBs")
> Signed-off-by: Gustavo Romero <gromero@linux.ibm.com>
> [desnesn: Only set MMCR0_PMAE when disabling MMCR0_FC, reflow
> comment]
> Signed-off-by: Desnes A. Nunes do Rosario <desnesn@linux.ibm.com>
Reviewed and Tested-by: Rashmica Gupta <rashmica.g@gmail.com>
> ---
> .../testing/selftests/powerpc/pmu/ebb/cycles_with_freeze_test.c | 2
> +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
> a/tools/testing/selftests/powerpc/pmu/ebb/cycles_with_freeze_test.c
> b/tools/testing/selftests/powerpc/pmu/ebb/cycles_with_freeze_test.c
> index 0f2089f6f82c..d368199144fb 100644
> ---
> a/tools/testing/selftests/powerpc/pmu/ebb/cycles_with_freeze_test.c
> +++
> b/tools/testing/selftests/powerpc/pmu/ebb/cycles_with_freeze_test.c
> @@ -81,7 +81,7 @@ int cycles_with_freeze(void)
> {
> counters_frozen = false;
> mb();
> - mtspr(SPRN_MMCR0, mfspr(SPRN_MMCR0) & ~MMCR0_FC);
> + mtspr(SPRN_MMCR0, (mfspr(SPRN_MMCR0) & ~MMCR0_FC) |
> MMCR0_PMAE);
>
> FAIL_IF(core_busy_loop());
>
^ permalink raw reply
* Re: [PATCH 16/21] mm: remove early_pfn_in_nid() and CONFIG_NODES_SPAN_OTHER_NODES
From: Mike Rapoport @ 2020-04-23 5:50 UTC (permalink / raw)
To: Baoquan He
Cc: Rich Felker, linux-ia64, linux-doc, Catalin Marinas,
Heiko Carstens, Michal Hocko, James E.J. Bottomley, Max Filippov,
Guo Ren, linux-csky, linux-parisc, sparclinux, linux-hexagon,
linux-riscv, Greg Ungerer, linux-arch, linux-s390, linux-snps-arc,
linux-c6x-dev, Brian Cain, Jonathan Corbet, linux-sh,
Helge Deller, x86, Russell King, Ley Foon Tan, Mike Rapoport,
Geert Uytterhoeven, linux-arm-kernel, Mark Salter, Matt Turner,
linux-mips, uclinux-h8-devel, linux-xtensa, linux-alpha, linux-um,
linux-m68k, Tony Luck, Greentime Hu, Paul Walmsley,
Stafford Horne, Guan Xuetao, Hoan Tran, Michal Simek,
Thomas Bogendoerfer, Yoshinori Sato, Nick Hu, linux-mm,
Vineet Gupta, linux-kernel, openrisc, Richard Weinberger,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200423011312.GY4247@MiWiFi-R3L-srv>
On Thu, Apr 23, 2020 at 09:13:12AM +0800, Baoquan He wrote:
> On 04/12/20 at 10:48pm, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt@linux.ibm.com>
> >
> > The commit f47ac088c406 ("mm: memmap_init: iterate over memblock regions
>
> This commit id should be a temporary one, will be changed when merged
> into maintainer's tree and linus's tree. Only saying last patch plus the
> patch subject is OK?
Right, the commit id here is not stable. I'll update the changelog.
> > rather that check each PFN") made early_pfn_in_nid() obsolete and since
> > CONFIG_NODES_SPAN_OTHER_NODES is only used to pick a stub or a real
> > implementation of early_pfn_in_nid() it is also not needed anymore.
> >
> > Remove both early_pfn_in_nid() and the CONFIG_NODES_SPAN_OTHER_NODES.
> >
> > Co-developed-by: Hoan Tran <Hoan@os.amperecomputing.com>
> > Signed-off-by: Hoan Tran <Hoan@os.amperecomputing.com>
> > Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> > ---
> > arch/powerpc/Kconfig | 9 ---------
> > arch/sparc/Kconfig | 9 ---------
> > arch/x86/Kconfig | 9 ---------
> > mm/page_alloc.c | 20 --------------------
> > 4 files changed, 47 deletions(-)
> >
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index 5f86b22b7d2c..74f316deeae1 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -685,15 +685,6 @@ config ARCH_MEMORY_PROBE
> > def_bool y
> > depends on MEMORY_HOTPLUG
> >
> > -# Some NUMA nodes have memory ranges that span
> > -# other nodes. Even though a pfn is valid and
> > -# between a node's start and end pfns, it may not
> > -# reside on that node. See memmap_init_zone()
> > -# for details.
> > -config NODES_SPAN_OTHER_NODES
> > - def_bool y
> > - depends on NEED_MULTIPLE_NODES
> > -
> > config STDBINUTILS
> > bool "Using standard binutils settings"
> > depends on 44x
> > diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
> > index 795206b7b552..0e4f3891b904 100644
> > --- a/arch/sparc/Kconfig
> > +++ b/arch/sparc/Kconfig
> > @@ -286,15 +286,6 @@ config NODES_SHIFT
> > Specify the maximum number of NUMA Nodes available on the target
> > system. Increases memory reserved to accommodate various tables.
> >
> > -# Some NUMA nodes have memory ranges that span
> > -# other nodes. Even though a pfn is valid and
> > -# between a node's start and end pfns, it may not
> > -# reside on that node. See memmap_init_zone()
> > -# for details.
> > -config NODES_SPAN_OTHER_NODES
> > - def_bool y
> > - depends on NEED_MULTIPLE_NODES
> > -
> > config ARCH_SPARSEMEM_ENABLE
> > def_bool y if SPARC64
> > select SPARSEMEM_VMEMMAP_ENABLE
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index 9d3e95b4fb85..37dac095659e 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -1581,15 +1581,6 @@ config X86_64_ACPI_NUMA
> > ---help---
> > Enable ACPI SRAT based node topology detection.
> >
> > -# Some NUMA nodes have memory ranges that span
> > -# other nodes. Even though a pfn is valid and
> > -# between a node's start and end pfns, it may not
> > -# reside on that node. See memmap_init_zone()
> > -# for details.
> > -config NODES_SPAN_OTHER_NODES
> > - def_bool y
> > - depends on X86_64_ACPI_NUMA
> > -
> > config NUMA_EMU
> > bool "NUMA emulation"
> > depends on NUMA
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index c43ce8709457..343d87b8697d 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -1541,26 +1541,6 @@ int __meminit early_pfn_to_nid(unsigned long pfn)
> > }
> > #endif /* CONFIG_NEED_MULTIPLE_NODES */
> >
> > -#ifdef CONFIG_NODES_SPAN_OTHER_NODES
> > -/* Only safe to use early in boot when initialisation is single-threaded */
> > -static inline bool __meminit early_pfn_in_nid(unsigned long pfn, int node)
> > -{
> > - int nid;
> > -
> > - nid = __early_pfn_to_nid(pfn, &early_pfnnid_cache);
> > - if (nid >= 0 && nid != node)
> > - return false;
> > - return true;
> > -}
> > -
> > -#else
> > -static inline bool __meminit early_pfn_in_nid(unsigned long pfn, int node)
> > -{
> > - return true;
> > -}
> > -#endif
>
> And macro early_pfn_valid() is not needed either, we may need remove it
> too.
Ok.
> Otherwise, removing NODES_SPAN_OTHER_NODES in this patch looks good.
>
> Reviewed-by: Baoquan He <bhe@redhat.com>
>
> > -
> > -
> > void __init memblock_free_pages(struct page *page, unsigned long pfn,
> > unsigned int order)
> > {
> > --
> > 2.25.1
> >
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH 3/3] selftests/powerpc: ensure PMC reads are set and ordered on count_pmc
From: Rashmica Gupta @ 2020-04-23 5:54 UTC (permalink / raw)
To: Desnes A. Nunes do Rosario, linuxppc-dev; +Cc: shuah, gromero
In-Reply-To: <20200408223543.21168-4-desnesn@linux.ibm.com>
On Wed, 2020-04-08 at 19:35 -0300, Desnes A. Nunes do Rosario wrote:
> Function count_pmc() needs a memory barrier to ensure that PMC reads
> are
> fully consistent. The lack of it can occasionally fail pmc56_overflow
> test,
> since depending on the workload on the system, PMC5 & 6 can have past
> val-
> ues from the time the counters are frozen and turned back on. These
> past
> values will be accounted as overflows and make the test fail.
>
> =========
> test: pmc56_overflow
> ...
> ebb_state:
> ...
> > > pmc[5] count = 0xfd4cbc8c
> > > pmc[6] count = 0xddd8b3b6
> HW state:
> MMCR0 0x0000000084000000 FC PMAE
> MMCR2 0x0000000000000000
> EBBHR 0x0000000010003f68
> BESCR 0x8000000000000000 GE
> ...
> PMC5 0x0000000000000000
> PMC6 0x0000000000000000
> SIAR 0x0000000010003398
> ...
> [3]: register SPRN_PMC2 = 0x0000000080000003
> [4]: register SPRN_PMC5 = 0x0000000000000000
> [5]: register SPRN_PMC6 = 0x0000000000000000
> [6]: register SPRN_PMC2 = 0x0000000080000003
> > > [7]: register SPRN_PMC5 = 0x000000008f21266d
> > > [8]: register SPRN_PMC6 = 0x000000000da80f8d
> [9]: register SPRN_PMC2 = 0x0000000080000003
> > > [10]: register SPRN_PMC5 = 0x000000006e2b961f
> > > [11]: register SPRN_PMC6 = 0x00000000d030a429
> [12]: register SPRN_PMC2 = 0x0000000080000003
> [13]: register SPRN_PMC5 = 0x0000000000000000
> [14]: register SPRN_PMC6 = 0x0000000000000000
> ...
> PMC5/6 overflow 2
> [FAIL] Test FAILED on line 87
> failure: pmc56_overflow
> =========
>
> Signed-off-by: Desnes A. Nunes do Rosario <desnesn@linux.ibm.com>
Reviewed-by: Rashmica Gupta <rashmica.g@gmail.com>
> ---
> tools/testing/selftests/powerpc/pmu/ebb/ebb.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/tools/testing/selftests/powerpc/pmu/ebb/ebb.c
> b/tools/testing/selftests/powerpc/pmu/ebb/ebb.c
> index bf6f25dfcf7b..6199f3cea0f9 100644
> --- a/tools/testing/selftests/powerpc/pmu/ebb/ebb.c
> +++ b/tools/testing/selftests/powerpc/pmu/ebb/ebb.c
> @@ -258,6 +258,10 @@ int count_pmc(int pmc, uint32_t sample_period)
> start_value = pmc_sample_period(sample_period);
>
> val = read_pmc(pmc);
> +
> + /* Ensure pmc value is consistent between freezes */
> + mb();
> +
> if (val < start_value)
> ebb_state.stats.negative++;
> else
^ permalink raw reply
* Re: [PATCH 17/21] mm: free_area_init: allow defining max_zone_pfn in descending order
From: Mike Rapoport @ 2020-04-23 5:55 UTC (permalink / raw)
To: Baoquan He
Cc: Rich Felker, linux-ia64, linux-doc, Catalin Marinas,
Heiko Carstens, Michal Hocko, James E.J. Bottomley, Max Filippov,
Guo Ren, linux-csky, linux-parisc, sparclinux, linux-hexagon,
linux-riscv, Greg Ungerer, linux-arch, linux-s390, linux-snps-arc,
linux-c6x-dev, Brian Cain, Jonathan Corbet, linux-sh,
Helge Deller, x86, Russell King, Ley Foon Tan, Mike Rapoport,
Geert Uytterhoeven, linux-arm-kernel, Mark Salter, Matt Turner,
linux-mips, uclinux-h8-devel, linux-xtensa, linux-alpha, linux-um,
linux-m68k, Tony Luck, Greentime Hu, Paul Walmsley,
Stafford Horne, Guan Xuetao, Hoan Tran, Michal Simek,
Thomas Bogendoerfer, Yoshinori Sato, Nick Hu, linux-mm,
Vineet Gupta, linux-kernel, openrisc, Richard Weinberger,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200423025720.GA4247@MiWiFi-R3L-srv>
On Thu, Apr 23, 2020 at 10:57:20AM +0800, Baoquan He wrote:
> On 04/23/20 at 10:53am, Baoquan He wrote:
> > On 04/12/20 at 10:48pm, Mike Rapoport wrote:
> > > From: Mike Rapoport <rppt@linux.ibm.com>
> > >
> > > Some architectures (e.g. ARC) have the ZONE_HIGHMEM zone below the
> > > ZONE_NORMAL. Allowing free_area_init() parse max_zone_pfn array even it is
> > > sorted in descending order allows using free_area_init() on such
> > > architectures.
> > >
> > > Add top -> down traversal of max_zone_pfn array in free_area_init() and use
> > > the latter in ARC node/zone initialization.
> >
> > Or maybe leave ARC as is. The change in this patchset doesn't impact
> > ARC's handling about zone initialization, leaving it as is can reduce
> > the complication in implementation of free_area_init(), which is a
> > common function. So I personally don't see a strong motivation to have
> > this patch.
>
> OK, seems this patch is prepared to simplify free_area_init_node(), so
> take back what I said at above.
>
> Then this looks necessary, even though it introduces special case into
> common function free_area_init().
The idea is to have a single free_area_init() for all architectures
without keeping two completely different ways of calculating the zone
extents.
Another thing, is that with this we could eventually switch ARC from
DISCONTIGMEM.
> Reviewed-by: Baoquan He <bhe@redhat.com>
>
> >
> > >
> > > Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> > > ---
> > > arch/arc/mm/init.c | 36 +++++++-----------------------------
> > > mm/page_alloc.c | 24 +++++++++++++++++++-----
> > > 2 files changed, 26 insertions(+), 34 deletions(-)
> > >
> > > diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
> > > index 0920c969c466..41eb9be1653c 100644
> > > --- a/arch/arc/mm/init.c
> > > +++ b/arch/arc/mm/init.c
> > > @@ -63,11 +63,13 @@ void __init early_init_dt_add_memory_arch(u64 base, u64 size)
> > >
> > > low_mem_sz = size;
> > > in_use = 1;
> > > + memblock_add_node(base, size, 0);
> > > } else {
> > > #ifdef CONFIG_HIGHMEM
> > > high_mem_start = base;
> > > high_mem_sz = size;
> > > in_use = 1;
> > > + memblock_add_node(base, size, 1);
> > > #endif
> > > }
> > >
> > > @@ -83,8 +85,7 @@ void __init early_init_dt_add_memory_arch(u64 base, u64 size)
> > > */
> > > void __init setup_arch_memory(void)
> > > {
> > > - unsigned long zones_size[MAX_NR_ZONES];
> > > - unsigned long zones_holes[MAX_NR_ZONES];
> > > + unsigned long max_zone_pfn[MAX_NR_ZONES] = { 0 };
> > >
> > > init_mm.start_code = (unsigned long)_text;
> > > init_mm.end_code = (unsigned long)_etext;
> > > @@ -115,7 +116,6 @@ void __init setup_arch_memory(void)
> > > * the crash
> > > */
> > >
> > > - memblock_add_node(low_mem_start, low_mem_sz, 0);
> > > memblock_reserve(CONFIG_LINUX_LINK_BASE,
> > > __pa(_end) - CONFIG_LINUX_LINK_BASE);
> > >
> > > @@ -133,22 +133,7 @@ void __init setup_arch_memory(void)
> > > memblock_dump_all();
> > >
> > > /*----------------- node/zones setup --------------------------*/
> > > - memset(zones_size, 0, sizeof(zones_size));
> > > - memset(zones_holes, 0, sizeof(zones_holes));
> > > -
> > > - zones_size[ZONE_NORMAL] = max_low_pfn - min_low_pfn;
> > > - zones_holes[ZONE_NORMAL] = 0;
> > > -
> > > - /*
> > > - * We can't use the helper free_area_init(zones[]) because it uses
> > > - * PAGE_OFFSET to compute the @min_low_pfn which would be wrong
> > > - * when our kernel doesn't start at PAGE_OFFSET, i.e.
> > > - * PAGE_OFFSET != CONFIG_LINUX_RAM_BASE
> > > - */
> > > - free_area_init_node(0, /* node-id */
> > > - zones_size, /* num pages per zone */
> > > - min_low_pfn, /* first pfn of node */
> > > - zones_holes); /* holes */
> > > + max_zone_pfn[ZONE_NORMAL] = max_low_pfn;
> > >
> > > #ifdef CONFIG_HIGHMEM
> > > /*
> > > @@ -168,20 +153,13 @@ void __init setup_arch_memory(void)
> > > min_high_pfn = PFN_DOWN(high_mem_start);
> > > max_high_pfn = PFN_DOWN(high_mem_start + high_mem_sz);
> > >
> > > - zones_size[ZONE_NORMAL] = 0;
> > > - zones_holes[ZONE_NORMAL] = 0;
> > > -
> > > - zones_size[ZONE_HIGHMEM] = max_high_pfn - min_high_pfn;
> > > - zones_holes[ZONE_HIGHMEM] = 0;
> > > -
> > > - free_area_init_node(1, /* node-id */
> > > - zones_size, /* num pages per zone */
> > > - min_high_pfn, /* first pfn of node */
> > > - zones_holes); /* holes */
> > > + max_zone_pfn[ZONE_HIGHMEM] = max_high_pfn;
> > >
> > > high_memory = (void *)(min_high_pfn << PAGE_SHIFT);
> > > kmap_init();
> > > #endif
> > > +
> > > + free_area_init(max_zone_pfn);
> > > }
> > >
> > > /*
> > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > > index 343d87b8697d..376434c7a78b 100644
> > > --- a/mm/page_alloc.c
> > > +++ b/mm/page_alloc.c
> > > @@ -7429,7 +7429,8 @@ static void check_for_memory(pg_data_t *pgdat, int nid)
> > > void __init free_area_init(unsigned long *max_zone_pfn)
> > > {
> > > unsigned long start_pfn, end_pfn;
> > > - int i, nid;
> > > + int i, nid, zone;
> > > + bool descending = false;
> > >
> > > /* Record where the zone boundaries are */
> > > memset(arch_zone_lowest_possible_pfn, 0,
> > > @@ -7439,13 +7440,26 @@ void __init free_area_init(unsigned long *max_zone_pfn)
> > >
> > > start_pfn = find_min_pfn_with_active_regions();
> > >
> > > + /*
> > > + * Some architecturs, e.g. ARC may have ZONE_HIGHMEM below
> > > + * ZONE_NORMAL. For such cases we allow max_zone_pfn sorted in the
> > > + * descending order
> > > + */
> > > + if (MAX_NR_ZONES > 1 && max_zone_pfn[0] > max_zone_pfn[1])
> > > + descending = true;
> > > +
> > > for (i = 0; i < MAX_NR_ZONES; i++) {
> > > - if (i == ZONE_MOVABLE)
> > > + if (descending)
> > > + zone = MAX_NR_ZONES - i - 1;
> > > + else
> > > + zone = i;
> > > +
> > > + if (zone == ZONE_MOVABLE)
> > > continue;
> > >
> > > - end_pfn = max(max_zone_pfn[i], start_pfn);
> > > - arch_zone_lowest_possible_pfn[i] = start_pfn;
> > > - arch_zone_highest_possible_pfn[i] = end_pfn;
> > > + end_pfn = max(max_zone_pfn[zone], start_pfn);
> > > + arch_zone_lowest_possible_pfn[zone] = start_pfn;
> > > + arch_zone_highest_possible_pfn[zone] = end_pfn;
> > >
> > > start_pfn = end_pfn;
> > > }
> > > --
> > > 2.25.1
> > >
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* [PATCH] drivers/macintosh: Fix memleak in windfarm_pm112 driver
From: Michael Ellerman @ 2020-04-23 6:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: erhard_f
create_cpu_loop() calls smu_sat_get_sdb_partition() which does
kmalloc() and returns the allocated buffer. In fact it's called twice,
and neither buffer is freed.
This results in a memory leak as reported by Erhard:
unreferenced object 0xc00000047081f840 (size 32):
comm "kwindfarm", pid 203, jiffies 4294880630 (age 5552.877s)
hex dump (first 32 bytes):
c8 06 02 7f ff 02 ff 01 fb bf 00 41 00 20 00 00 ...........A. ..
00 07 89 37 00 a0 00 00 00 00 00 00 00 00 00 00 ...7............
backtrace:
[<0000000083f0a65c>] .smu_sat_get_sdb_partition+0xc4/0x2d0 [windfarm_smu_sat]
[<000000003010fcb7>] .pm112_wf_notify+0x104c/0x13bc [windfarm_pm112]
[<00000000b958b2dd>] .notifier_call_chain+0xa8/0x180
[<0000000070490868>] .blocking_notifier_call_chain+0x64/0x90
[<00000000131d8149>] .wf_thread_func+0x114/0x1a0
[<000000000d54838d>] .kthread+0x13c/0x190
[<00000000669b72bc>] .ret_from_kernel_thread+0x58/0x64
unreferenced object 0xc0000004737089f0 (size 16):
comm "kwindfarm", pid 203, jiffies 4294880879 (age 5552.050s)
hex dump (first 16 bytes):
c4 04 01 7f 22 11 e0 e6 ff 55 7b 12 ec 11 00 00 ...."....U{.....
backtrace:
[<0000000083f0a65c>] .smu_sat_get_sdb_partition+0xc4/0x2d0 [windfarm_smu_sat]
[<00000000b94ef7e1>] .pm112_wf_notify+0x1294/0x13bc [windfarm_pm112]
[<00000000b958b2dd>] .notifier_call_chain+0xa8/0x180
[<0000000070490868>] .blocking_notifier_call_chain+0x64/0x90
[<00000000131d8149>] .wf_thread_func+0x114/0x1a0
[<000000000d54838d>] .kthread+0x13c/0x190
[<00000000669b72bc>] .ret_from_kernel_thread+0x58/0x64
Fix it by rearranging the logic so we deal with each buffer
separately, which then makes it easy to free the buffer once we're
done with it.
Fixes: ac171c46667c ("[PATCH] powerpc: Thermal control for dual core G5s")
Cc: stable@vger.kernel.org # v2.6.16+
Reported-by: Erhard F. <erhard_f@mailbox.org>
Tested-by: Erhard F. <erhard_f@mailbox.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
drivers/macintosh/windfarm_pm112.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/macintosh/windfarm_pm112.c b/drivers/macintosh/windfarm_pm112.c
index 4150301a89a5..e8377ce0a95a 100644
--- a/drivers/macintosh/windfarm_pm112.c
+++ b/drivers/macintosh/windfarm_pm112.c
@@ -132,14 +132,6 @@ static int create_cpu_loop(int cpu)
s32 tmax;
int fmin;
- /* Get PID params from the appropriate SAT */
- hdr = smu_sat_get_sdb_partition(chip, 0xC8 + core, NULL);
- if (hdr == NULL) {
- printk(KERN_WARNING"windfarm: can't get CPU PID fan config\n");
- return -EINVAL;
- }
- piddata = (struct smu_sdbp_cpupiddata *)&hdr[1];
-
/* Get FVT params to get Tmax; if not found, assume default */
hdr = smu_sat_get_sdb_partition(chip, 0xC4 + core, NULL);
if (hdr) {
@@ -152,6 +144,16 @@ static int create_cpu_loop(int cpu)
if (tmax < cpu_all_tmax)
cpu_all_tmax = tmax;
+ kfree(hdr);
+
+ /* Get PID params from the appropriate SAT */
+ hdr = smu_sat_get_sdb_partition(chip, 0xC8 + core, NULL);
+ if (hdr == NULL) {
+ printk(KERN_WARNING"windfarm: can't get CPU PID fan config\n");
+ return -EINVAL;
+ }
+ piddata = (struct smu_sdbp_cpupiddata *)&hdr[1];
+
/*
* Darwin has a minimum fan speed of 1000 rpm for the 4-way and
* 515 for the 2-way. That appears to be overkill, so for now,
@@ -174,6 +176,9 @@ static int create_cpu_loop(int cpu)
pid.min = fmin;
wf_cpu_pid_init(&cpu_pid[cpu], &pid);
+
+ kfree(hdr);
+
return 0;
}
--
2.25.1
^ permalink raw reply related
* [Bug 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set
From: bugzilla-daemon @ 2020-04-23 6:11 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-199471-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=199471
Wolfram Sang (wsa@the-dreams.de) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |CODE_FIX
--- Comment #22 from Wolfram Sang (wsa@the-dreams.de) ---
Fixed upstream with commit bcf3588d8ed3517e6ffaf083f034812aee9dc8e2.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH 18/21] mm: rename free_area_init_node() to free_area_init_memoryless_node()
From: Mike Rapoport @ 2020-04-23 6:18 UTC (permalink / raw)
To: Baoquan He
Cc: Rich Felker, linux-ia64, linux-doc, Catalin Marinas,
Heiko Carstens, Michal Hocko, James E.J. Bottomley, Max Filippov,
Guo Ren, linux-csky, linux-parisc, sparclinux, linux-hexagon,
linux-riscv, Greg Ungerer, linux-arch, linux-s390, linux-snps-arc,
linux-c6x-dev, Brian Cain, Jonathan Corbet, linux-sh,
Helge Deller, x86, Russell King, Ley Foon Tan, Mike Rapoport,
Geert Uytterhoeven, linux-arm-kernel, Mark Salter, Matt Turner,
linux-mips, uclinux-h8-devel, linux-xtensa, linux-alpha, linux-um,
linux-m68k, Tony Luck, Greentime Hu, Paul Walmsley,
Stafford Horne, Guan Xuetao, Hoan Tran, Michal Simek,
Thomas Bogendoerfer, Yoshinori Sato, Nick Hu, linux-mm,
Vineet Gupta, linux-kernel, openrisc, Richard Weinberger,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200423031454.GB4247@MiWiFi-R3L-srv>
On Thu, Apr 23, 2020 at 11:14:54AM +0800, Baoquan He wrote:
> On 04/12/20 at 10:48pm, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt@linux.ibm.com>
> >
> > The free_area_init_node() is only used by x86 to initialize a memory-less
> > nodes.
> > Make its name reflect this and drop all the function parameters except node
> > ID as they are anyway zero.
> >
> > Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> > ---
> > arch/x86/mm/numa.c | 5 +----
> > include/linux/mm.h | 9 +++------
> > mm/page_alloc.c | 7 ++-----
> > 3 files changed, 6 insertions(+), 15 deletions(-)
> >
> > diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> > index fe024b2ac796..8ee952038c80 100644
> > --- a/arch/x86/mm/numa.c
> > +++ b/arch/x86/mm/numa.c
> > @@ -737,12 +737,9 @@ void __init x86_numa_init(void)
> >
> > static void __init init_memory_less_node(int nid)
> > {
> > - unsigned long zones_size[MAX_NR_ZONES] = {0};
> > - unsigned long zholes_size[MAX_NR_ZONES] = {0};
> > -
> > /* Allocate and initialize node data. Memory-less node is now online.*/
> > alloc_node_data(nid);
> > - free_area_init_node(nid, zones_size, 0, zholes_size);
> > + free_area_init_memoryless_node(nid);
> >
> > /*
> > * All zonelists will be built later in start_kernel() after per cpu
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index 1c2ecb42e043..27660f6cf26e 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -2272,8 +2272,7 @@ static inline spinlock_t *pud_lock(struct mm_struct *mm, pud_t *pud)
> > }
> >
> > extern void __init pagecache_init(void);
> > -extern void __init free_area_init_node(int nid, unsigned long * zones_size,
> > - unsigned long zone_start_pfn, unsigned long *zholes_size);
> > +extern void __init free_area_init_memoryless_node(int nid);
> > extern void free_initmem(void);
> >
> > /*
> > @@ -2345,10 +2344,8 @@ static inline unsigned long get_num_physpages(void)
> >
> > /*
> > * Using memblock node mappings, an architecture may initialise its
> > - * zones, allocate the backing mem_map and account for memory holes in a more
> > - * architecture independent manner. This is a substitute for creating the
> > - * zone_sizes[] and zholes_size[] arrays and passing them to
> > - * free_area_init_node()
> > + * zones, allocate the backing mem_map and account for memory holes in an
> > + * architecture independent manner.
> > *
> > * An architecture is expected to register range of page frames backed by
> > * physical memory with memblock_add[_node]() before calling
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 376434c7a78b..e46232ec4849 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -6979,12 +6979,9 @@ static void __init __free_area_init_node(int nid, unsigned long *zones_size,
> > free_area_init_core(pgdat);
> > }
> >
> > -void __init free_area_init_node(int nid, unsigned long *zones_size,
> > - unsigned long node_start_pfn,
> > - unsigned long *zholes_size)
> > +void __init free_area_init_memoryless_node(int nid)
> > {
> > - __free_area_init_node(nid, zones_size, node_start_pfn, zholes_size,
> > - true);
> > + __free_area_init_node(nid, NULL, 0, NULL, false);
>
> Can we move free_area_init_memoryless_node() definition into
> arch/x86/mm/numa.c since there's only one caller there?
>
> And I am also wondering if adding a wrapper
> free_area_init_memoryless_node() is necessary if it's only called the
> function free_area_init_node().
Yeah, I think this patch can be entirely dropped and the next one could
be slightly updated :)
Thanks!
> > }
> >
> > #if !defined(CONFIG_FLAT_NODE_MEM_MAP) --
> > 2.25.1
> >
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* [Bug 206695] kmemleak reports leaks in drivers/macintosh/windfarm
From: bugzilla-daemon @ 2020-04-23 6:53 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-206695-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=206695
Michael Ellerman (michael@ellerman.id.au) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
CC| |michael@ellerman.id.au
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 206695] kmemleak reports leaks in drivers/macintosh/windfarm
From: bugzilla-daemon @ 2020-04-23 6:54 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-206695-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=206695
Michael Ellerman (michael@ellerman.id.au) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |CODE_FIX
--- Comment #7 from Michael Ellerman (michael@ellerman.id.au) ---
Patch posted:
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20200423060038.3308530-1-mpe@ellerman.id.au/
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [PATCH][next] ASoC: fsl_easrc: fix spelling mistake "prefitler" -> "prefilter"
From: Colin King @ 2020-04-23 8:39 UTC (permalink / raw)
To: Timur Tabi, Nicolin Chen, Xiubo Li, Fabio Estevam, Liam Girdwood,
Mark Brown, Jaroslav Kysela, Takashi Iwai, alsa-devel,
linuxppc-dev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
There is a spelling mistake in a deb_dbg message, fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
sound/soc/fsl/fsl_easrc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_easrc.c b/sound/soc/fsl/fsl_easrc.c
index 233f26ff885c..97658e1f4989 100644
--- a/sound/soc/fsl/fsl_easrc.c
+++ b/sound/soc/fsl/fsl_easrc.c
@@ -1769,7 +1769,7 @@ static void fsl_easrc_dump_firmware(struct fsl_asrc *easrc)
}
dev_dbg(dev, "Firmware v%u dump:\n", firm->firmware_version);
- dev_dbg(dev, "Num prefitler scenarios: %u\n", firm->prefil_scen);
+ dev_dbg(dev, "Num prefilter scenarios: %u\n", firm->prefil_scen);
dev_dbg(dev, "Num interpolation scenarios: %u\n", firm->interp_scen);
dev_dbg(dev, "\nInterpolation scenarios:\n");
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v5 0/5] Track and expose idle PURR and SPURR ticks
From: Gautham R Shenoy @ 2020-04-23 10:02 UTC (permalink / raw)
To: Tyrel Datwyler
Cc: Nathan Lynch, Gautham R. Shenoy, linux-kernel, Kamalesh Babulal,
Naveen N. Rao, Vaidyanathan Srinivasan, linuxppc-dev
In-Reply-To: <04b5e2fa-089f-93c9-cde9-33a930455bb2@linux.ibm.com>
On Mon, Apr 20, 2020 at 03:46:35PM -0700, Tyrel Datwyler wrote:
> On 4/7/20 1:47 AM, Gautham R. Shenoy wrote:
> > From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
> >
> > Hi,
> >
> > This is the fifth version of the patches to track and expose idle PURR
> > and SPURR ticks. These patches are required by tools such as lparstat
> > to compute system utilization for capacity planning purposes.
> >
> > The previous versions can be found here:
> > v4: https://lkml.org/lkml/2020/3/27/323
> > v3: https://lkml.org/lkml/2020/3/11/331
> > v2: https://lkml.org/lkml/2020/2/21/21
> > v1: https://lore.kernel.org/patchwork/cover/1159341/
> >
> > They changes from v4 are:
> >
> > - As suggested by Naveen, moved the functions read_this_idle_purr()
> > and read_this_idle_spurr() from Patch 2 and Patch 3 respectively
> > to Patch 4 where it is invoked.
> >
> > - Dropped Patch 6 which cached the values of purr, spurr,
> > idle_purr, idle_spurr in order to minimize the number of IPIs
> > sent.
> >
> > - Updated the dates for the idle_purr, idle_spurr in the
> > Documentation Patch 5.
> >
> > Motivation:
> > ===========
> > On PSeries LPARs, the data centers planners desire a more accurate
> > view of system utilization per resource such as CPU to plan the system
> > capacity requirements better. Such accuracy can be obtained by reading
> > PURR/SPURR registers for CPU resource utilization.
> >
> > Tools such as lparstat which are used to compute the utilization need
> > to know [S]PURR ticks when the cpu was busy or idle. The [S]PURR
> > counters are already exposed through sysfs. We already account for
> > PURR ticks when we go to idle so that we can update the VPA area. This
> > patchset extends support to account for SPURR ticks when idle, and
> > expose both via per-cpu sysfs files.
> >
> > These patches are required for enhancement to the lparstat utility
> > that compute the CPU utilization based on PURR and SPURR which can be
> > found here :
> > https://groups.google.com/forum/#!topic/powerpc-utils-devel/fYRo69xO9r4
> >
> >
> > With the patches, when lparstat is run on a LPAR running CPU-Hogs,
> > =========================================================================
> > sudo ./src/lparstat -E 1 3
> >
> > System Configuration
> > type=Dedicated mode=Capped smt=8 lcpu=2 mem=4834112 kB cpus=0 ent=2.00
> >
> > ---Actual--- -Normalized-
> > %busy %idle Frequency %busy %idle
> > ------ ------ ------------- ------ ------
> > 1 99.99 0.00 3.35GHz[111%] 110.99 0.00
> > 2 100.00 0.00 3.35GHz[111%] 111.01 0.00
> > 3 100.00 0.00 3.35GHz[111%] 111.00 0.00
> >
> > With patches, when lparstat is run on and idle LPAR
> > =========================================================================
> > System Configuration
> > type=Dedicated mode=Capped smt=8 lcpu=2 mem=4834112 kB cpus=0 ent=2.00
> > ---Actual--- -Normalized-
> > %busy %idle Frequency %busy %idle
> > ------ ------ ------------- ------ ------
> > 1 0.15 99.84 2.17GHz[ 72%] 0.11 71.89
> > 2 0.24 99.76 2.11GHz[ 70%] 0.18 69.82
> > 3 0.24 99.75 2.11GHz[ 70%] 0.18 69.81
> >
> > Gautham R. Shenoy (5):
> > powerpc: Move idle_loop_prolog()/epilog() functions to header file
> > powerpc/idle: Store PURR snapshot in a per-cpu global variable
> > powerpc/pseries: Account for SPURR ticks on idle CPUs
> > powerpc/sysfs: Show idle_purr and idle_spurr for every CPU
> > Documentation: Document sysfs interfaces purr, spurr, idle_purr,
> > idle_spurr
> >
> > Documentation/ABI/testing/sysfs-devices-system-cpu | 39 +++++++++
> > arch/powerpc/include/asm/idle.h | 93 ++++++++++++++++++++++
> > arch/powerpc/kernel/sysfs.c | 82 ++++++++++++++++++-
> > arch/powerpc/platforms/pseries/setup.c | 8 +-
> > drivers/cpuidle/cpuidle-pseries.c | 39 ++-------
> > 5 files changed, 224 insertions(+), 37 deletions(-)
> > create mode 100644 arch/powerpc/include/asm/idle.h
> >
>
> Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Thanks for reviewing the patches.
>
> Any chance this is going to be merged in the near future? There is a patchset to
> update lparstat in the powerpc-utils package to calculate PURR/SPURR cpu
> utilization that I would like to merge, but have been holding off to make sure
> we are synced with this proposed patchset.
Michael, could you please consider this for 5.8 ?
--
Thanks and Regards
gautham.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox