* Re: [PATCH v6 00/15] memory-hotplug: hot-remove physical memory
From: Simon Jeons @ 2013-02-01 3:06 UTC (permalink / raw)
To: Tang Chen
Cc: linux-ia64, linux-sh, linux-mm, paulus, hpa, sparclinux, cl,
linux-s390, x86, linux-acpi, isimatu.yasuaki, linfeng, mgorman,
kosaki.motohiro, rientjes, len.brown, wency, cmetcalf, glommer,
Jianguo Wu, yinghai, laijs, linux-kernel, minchan.kim, akpm,
linuxppc-dev
In-Reply-To: <510B2B8A.7040407@cn.fujitsu.com>
Hi Tang,
On Fri, 2013-02-01 at 10:42 +0800, Tang Chen wrote:
I confuse!
> Hi Simon,
>
> On 02/01/2013 10:17 AM, Simon Jeons wrote:
> >> For example:
> >>
> >> 64TB, what ever
> >> xxxTB, what ever
> >> logic address space: |_____kernel_______|_________user_________________|
> >> \ \ / /
> >> \ /\ /
> >> physical address space: |___\/__\/_____________| 4GB or
> >> 8GB, what ever
> >> *****
> >
> > How much address space user process can have on x86_64? Also 8GB?
>
> Usually, we don't say that.
>
> 8GB is your physical memory, right ?
> But kernel space and user space is the logic conception in OS. They are
> in logic
> address space.
>
> So both the kernel space and the user space can use all the physical memory.
> But if the page is already in use by either of them, the other one
> cannot use it.
> For example, some pages are direct mapped to kernel, and is in use by
> kernel, the
> user space cannot map it.
How can distinguish map and use? I mean how can confirm memory is used
by kernel instead of map?
>
> >
> >>
> >> The ***** part physical is mapped to user space in the process' own
> >> pagetable.
> >> It is also direct mapped in kernel's pagetable. So the kernel can also
> >> access it. :)
> >
> > But how to protect user process not modify kernel memory?
>
> This is the job of CPU. On intel cpus, user space code is running in
> level 3, and
> kernel space code is running in level 0. So the code in level 3 cannot
> access the data
> segment in level 0.
1) If user process and kenel map to same physical memory, user process
will get SIGSEGV during #PF if access to this memory, but If user proces
s will map to the same memory which kernel map? Why? It can't access it.
2) If two user processes map to same physical memory, what will happen
if one process access the memory?
>
> Thanks. :)
^ permalink raw reply
* Re: [PATCH] powerpc: kernel/kgdb.c: fix memory leakage
From: Jason Wessel @ 2013-02-01 2:04 UTC (permalink / raw)
To: Cong Ding
Cc: Stephen Rothwell, Michael Neuling, linux-kernel, Tiejun Chen,
Paul Mackerras, linuxppc-dev
In-Reply-To: <1358184395-31418-1-git-send-email-dinggnu@gmail.com>
On 01/14/2013 11:26 AM, Cong Ding wrote:
> the variable backup_current_thread_info isn't freed before existing the
> function.
>
> Signed-off-by: Cong Ding <dinggnu@gmail.com>
> ---
> arch/powerpc/kernel/kgdb.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
> index 8747447..5ca82cd 100644
> --- a/arch/powerpc/kernel/kgdb.c
> +++ b/arch/powerpc/kernel/kgdb.c
> @@ -154,12 +154,12 @@ static int kgdb_handle_breakpoint(struct pt_regs *regs)
> static int kgdb_singlestep(struct pt_regs *regs)
> {
> struct thread_info *thread_info, *exception_thread_info;
> - struct thread_info *backup_current_thread_info = \
> - (struct thread_info *)kmalloc(sizeof(struct thread_info), GFP_KERNEL);
> + struct thread_info *backup_current_thread_info;
Woh... This is definitely wrong. You have found a problem for sure,
but this is not the right way to fix it.
It is not a good idea to kmalloc while single stepping because you can
hang the kernel if you single step any operation in kmalloc().
I am in the process of going through all the kgdb mails from the last
few months while I had been away from the project, so I didn't catch
this one and I see it has upstream commit (fefd9e6f8). I'll submit
another patch to fix this the right way and use a static variable.
This is ok to use a static variable here because this is not something
we can recursively call at a single CPU level.
If Ben prefers we not burn the memory unless kgdb is active we can
kmalloc / kfree the space we need at the time that kgdb is
initialized. Else we can go with this patch you see below. We'll see
what Ben desires.
-----
diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
index a7bc752..bb12c8b 100644
--- a/arch/powerpc/kernel/kgdb.c
+++ b/arch/powerpc/kernel/kgdb.c
@@ -151,15 +151,16 @@ static int kgdb_handle_breakpoint(struct pt_regs *regs)
return 1;
}
+static struct thread_info kgdb_backup_thread_info[NR_CPUS];
+
static int kgdb_singlestep(struct pt_regs *regs)
{
struct thread_info *thread_info, *exception_thread_info;
- struct thread_info *backup_current_thread_info;
+ int cpu = raw_smp_processor_id();
if (user_mode(regs))
return 0;
- backup_current_thread_info = (struct thread_info *)kmalloc(sizeof(struct thread_info), GFP_KERNEL);
/*
* On Book E and perhaps other processors, singlestep is handled on
* the critical exception stack. This causes current_thread_info()
@@ -175,7 +176,7 @@ static int kgdb_singlestep(struct pt_regs *regs)
if (thread_info != exception_thread_info) {
/* Save the original current_thread_info. */
- memcpy(backup_current_thread_info, exception_thread_info, sizeof *thread_info);
+ memcpy(&kgdb_backup_thread_info[cpu], exception_thread_info, sizeof *thread_info);
memcpy(exception_thread_info, thread_info, sizeof *thread_info);
}
@@ -183,9 +184,8 @@ static int kgdb_singlestep(struct pt_regs *regs)
if (thread_info != exception_thread_info)
/* Restore current_thread_info lastly. */
- memcpy(exception_thread_info, backup_current_thread_info, sizeof *thread_info);
+ memcpy(exception_thread_info, &kgdb_backup_thread_info[cpu], sizeof *thread_info);
- kfree(backup_current_thread_info);
return 1;
}
-----
Thanks,
Jason.
>
> if (user_mode(regs))
> return 0;
>
> + backup_current_thread_info = (struct thread_info *)kmalloc(sizeof(struct thread_info), GFP_KERNEL);
> /*
> * On Book E and perhaps other processors, singlestep is handled on
> * the critical exception stack. This causes current_thread_info()
> @@ -185,6 +185,7 @@ static int kgdb_singlestep(struct pt_regs *regs)
> /* Restore current_thread_info lastly. */
> memcpy(exception_thread_info, backup_current_thread_info, sizeof *thread_info);
>
> + kfree(backup_current_thread_info);
> return 1;
> }
>
>
^ permalink raw reply related
* Re: [PATCH v6 00/15] memory-hotplug: hot-remove physical memory
From: Simon Jeons @ 2013-02-01 2:17 UTC (permalink / raw)
To: Tang Chen
Cc: linux-ia64, linux-sh, linux-mm, paulus, hpa, sparclinux, cl,
linux-s390, x86, linux-acpi, isimatu.yasuaki, linfeng, mgorman,
kosaki.motohiro, rientjes, len.brown, wency, cmetcalf, glommer,
Jianguo Wu, yinghai, laijs, linux-kernel, minchan.kim, akpm,
linuxppc-dev
In-Reply-To: <510B20F9.10408@cn.fujitsu.com>
Hi Tang,
On Fri, 2013-02-01 at 09:57 +0800, Tang Chen wrote:
> On 02/01/2013 09:36 AM, Simon Jeons wrote:
> > On Fri, 2013-02-01 at 09:32 +0800, Jianguo Wu wrote:
> >>>
> >>> So if config NUMA, kernel memory will not be linear mapping anymore? For
> >>> example,
> >>>
> >>> Node 0 Node 1
> >>>
> >>> 0 ~ 10G 11G~14G
>
> It has nothing to do with linear mapping, I think.
>
> >>>
> >>> kernel memory only at Node 0? Can part of kernel memory also at Node 1?
>
> Please refer to find_zone_movable_pfns_for_nodes().
I see, thanks. :)
> The kernel is not only on node0. It uses all the online nodes evenly. :)
>
> >>>
> >>> How big is kernel direct mapping memory in x86_64? Is there max limit?
> >>
> >>
> >> Max kernel direct mapping memory in x86_64 is 64TB.
> >
> > For example, I have 8G memory, all of them will be direct mapping for
> > kernel? then userspace memory allocated from where?
>
> I think you misunderstood what Wu tried to say. :)
>
> The kernel mapped that large space, it doesn't mean it is using that
> large space.
> The mapping is to make kernel be able to access all the memory, not for
> the kernel
> to use only. User space can also use the memory, but each process has
> its own mapping.
>
> For example:
>
> 64TB, what ever
> xxxTB, what ever
> logic address space: |_____kernel_______|_________user_________________|
> \ \ / /
> \ /\ /
> physical address space: |___\/__\/_____________| 4GB or
> 8GB, what ever
> *****
How much address space user process can have on x86_64? Also 8GB?
>
> The ***** part physical is mapped to user space in the process' own
> pagetable.
> It is also direct mapped in kernel's pagetable. So the kernel can also
> access it. :)
But how to protect user process not modify kernel memory?
>
> >
> >>
> >>> It seems that only around 896MB on x86_32.
> >>>
> >>>>
> >>>> We need firmware take part in, such as SRAT in ACPI BIOS, or the firmware
> >>>> based memory migration mentioned by Liu Jiang.
> >>>
> >>> Is there any material about firmware based memory migration?
>
> No, I don't have any because this is a functionality of machine from HUAWEI.
> I think you can ask Liu Jiang or Wu Jianguo to share some with you. :)
>
> Thanks. :)
^ permalink raw reply
* Re: [PATCH v6 00/15] memory-hotplug: hot-remove physical memory
From: Tang Chen @ 2013-02-01 2:42 UTC (permalink / raw)
To: Simon Jeons
Cc: linux-ia64, linux-sh, linux-mm, paulus, hpa, sparclinux, cl,
linux-s390, x86, linux-acpi, isimatu.yasuaki, linfeng, mgorman,
kosaki.motohiro, rientjes, len.brown, wency, cmetcalf, glommer,
Jianguo Wu, yinghai, laijs, linux-kernel, minchan.kim, akpm,
linuxppc-dev
In-Reply-To: <1359685040.1303.6.camel@kernel>
Hi Simon,
On 02/01/2013 10:17 AM, Simon Jeons wrote:
>> For example:
>>
>> 64TB, what ever
>> xxxTB, what ever
>> logic address space: |_____kernel_______|_________user_________________|
>> \ \ / /
>> \ /\ /
>> physical address space: |___\/__\/_____________| 4GB or
>> 8GB, what ever
>> *****
>
> How much address space user process can have on x86_64? Also 8GB?
Usually, we don't say that.
8GB is your physical memory, right ?
But kernel space and user space is the logic conception in OS. They are
in logic
address space.
So both the kernel space and the user space can use all the physical memory.
But if the page is already in use by either of them, the other one
cannot use it.
For example, some pages are direct mapped to kernel, and is in use by
kernel, the
user space cannot map it.
>
>>
>> The ***** part physical is mapped to user space in the process' own
>> pagetable.
>> It is also direct mapped in kernel's pagetable. So the kernel can also
>> access it. :)
>
> But how to protect user process not modify kernel memory?
This is the job of CPU. On intel cpus, user space code is running in
level 3, and
kernel space code is running in level 0. So the code in level 3 cannot
access the data
segment in level 0.
Thanks. :)
^ permalink raw reply
* Re: [PATCH v6 00/15] memory-hotplug: hot-remove physical memory
From: Jianguo Wu @ 2013-02-01 2:18 UTC (permalink / raw)
To: Simon Jeons
Cc: linux-ia64, linux-sh, Tang Chen, linux-mm, paulus, hpa,
sparclinux, cl, linux-s390, x86, linux-acpi, isimatu.yasuaki,
linfeng, mgorman, kosaki.motohiro, rientjes, len.brown, wency,
cmetcalf, glommer, yinghai, laijs, linux-kernel, minchan.kim,
akpm, linuxppc-dev
In-Reply-To: <1359684403.1303.3.camel@kernel>
On 2013/2/1 10:06, Simon Jeons wrote:
> Hi Jianguo,
> On Fri, 2013-02-01 at 09:57 +0800, Jianguo Wu wrote:
>> On 2013/2/1 9:36, Simon Jeons wrote:
>>
>>> On Fri, 2013-02-01 at 09:32 +0800, Jianguo Wu wrote:
>>>> On 2013/1/31 18:38, Simon Jeons wrote:
>>>>
>>>>> Hi Tang,
>>>>> On Thu, 2013-01-31 at 17:44 +0800, Tang Chen wrote:
>>>>>> Hi Simon,
>>>>>>
>>>>>> On 01/31/2013 04:48 PM, Simon Jeons wrote:
>>>>>>> Hi Tang,
>>>>>>> On Thu, 2013-01-31 at 15:10 +0800, Tang Chen wrote:
>>>>>>>
>>>>>>> 1. IIUC, there is a button on machine which supports hot-remove memory,
>>>>>>> then what's the difference between press button and echo to /sys?
>>>>>>
>>>>>> No important difference, I think. Since I don't have the machine you are
>>>>>> saying, I cannot surely answer you. :)
>>>>>> AFAIK, pressing the button means trigger the hotplug from hardware, sysfs
>>>>>> is just another entrance. At last, they will run into the same code.
>>>>>>
>>>>>>> 2. Since kernel memory is linear mapping(I mean direct mapping part),
>>>>>>> why can't put kernel direct mapping memory into one memory device, and
>>>>>>> other memory into the other devices?
>>>>>>
>>>>>> We cannot do that because in that way, we will lose NUMA performance.
>>>>>>
>>>>>> If you know NUMA, you will understand the following example:
>>>>>>
>>>>>> node0: node1:
>>>>>> cpu0~cpu15 cpu16~cpu31
>>>>>> memory0~memory511 memory512~memory1023
>>>>>>
>>>>>> cpu16~cpu31 access memory16~memory1023 much faster than memory0~memory511.
>>>>>> If we set direct mapping area in node0, and movable area in node1, then
>>>>>> the kernel code running on cpu16~cpu31 will have to access
>>>>>> memory0~memory511.
>>>>>> This is a terrible performance down.
>>>>>
>>>>> So if config NUMA, kernel memory will not be linear mapping anymore? For
>>>>> example,
>>>>>
>>>>> Node 0 Node 1
>>>>>
>>>>> 0 ~ 10G 11G~14G
>>>>>
>>>>> kernel memory only at Node 0? Can part of kernel memory also at Node 1?
>>>>>
>>>>> How big is kernel direct mapping memory in x86_64? Is there max limit?
>>>>
>>>>
>>>> Max kernel direct mapping memory in x86_64 is 64TB.
>>>
>>> For example, I have 8G memory, all of them will be direct mapping for
>>> kernel? then userspace memory allocated from where?
>>
>> Direct mapping memory means you can use __va() and pa(), but not means that them
>> can be only used by kernel, them can be used by user-space too, as long as them are free.
>
> IIUC, the benefit of va() and pa() is just for quick get
> virtual/physical address, it takes advantage of linear mapping. But mmu
> still need to go through pgd/pud/pmd/pte, correct?
Yes.
>
>>
>>>
>>>>
>>>>> It seems that only around 896MB on x86_32.
>>>>>
>>>>>>
>>>>>>> As you know x86_64 don't need
>>>>>>> highmem, IIUC, all kernel memory will linear mapping in this case. Is my
>>>>>>> idea available? If is correct, x86_32 can't implement in the same way
>>>>>>> since highmem(kmap/kmap_atomic/vmalloc) can map any address, so it's
>>>>>>> hard to focus kernel memory on single memory device.
>>>>>>
>>>>>> Sorry, I'm not quite familiar with x86_32 box.
>>>>>>
>>>>>>> 3. In current implementation, if memory hotplug just need memory
>>>>>>> subsystem and ACPI codes support? Or also needs firmware take part in?
>>>>>>> Hope you can explain in details, thanks in advance. :)
>>>>>>
>>>>>> We need firmware take part in, such as SRAT in ACPI BIOS, or the firmware
>>>>>> based memory migration mentioned by Liu Jiang.
>>>>>
>>>>> Is there any material about firmware based memory migration?
>>>>>
>>>>>>
>>>>>> So far, I only know this. :)
>>>>>>
>>>>>>> 4. What's the status of memory hotplug? Apart from can't remove kernel
>>>>>>> memory, other things are fully implementation?
>>>>>>
>>>>>> I think the main job is done for now. And there are still bugs to fix.
>>>>>> And this functionality is not stable.
>>>>>>
>>>>>> Thanks. :)
>>>>>
>>>>>
>>>>> --
>>>>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>>>>> the body to majordomo@kvack.org. For more info on Linux MM,
>>>>> see: http://www.linux-mm.org/ .
>>>>> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>>>>>
>>>>> .
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> .
>>>
>>
>>
>>
>
>
>
> .
>
^ permalink raw reply
* Re: [PATCH v6 00/15] memory-hotplug: hot-remove physical memory
From: Simon Jeons @ 2013-02-01 2:06 UTC (permalink / raw)
To: Jianguo Wu
Cc: linux-ia64, linux-sh, Tang Chen, linux-mm, paulus, hpa,
sparclinux, cl, linux-s390, x86, linux-acpi, isimatu.yasuaki,
linfeng, mgorman, kosaki.motohiro, rientjes, len.brown, wency,
cmetcalf, glommer, yinghai, laijs, linux-kernel, minchan.kim,
akpm, linuxppc-dev
In-Reply-To: <510B20F2.20906@huawei.com>
Hi Jianguo,
On Fri, 2013-02-01 at 09:57 +0800, Jianguo Wu wrote:
> On 2013/2/1 9:36, Simon Jeons wrote:
>
> > On Fri, 2013-02-01 at 09:32 +0800, Jianguo Wu wrote:
> >> On 2013/1/31 18:38, Simon Jeons wrote:
> >>
> >>> Hi Tang,
> >>> On Thu, 2013-01-31 at 17:44 +0800, Tang Chen wrote:
> >>>> Hi Simon,
> >>>>
> >>>> On 01/31/2013 04:48 PM, Simon Jeons wrote:
> >>>>> Hi Tang,
> >>>>> On Thu, 2013-01-31 at 15:10 +0800, Tang Chen wrote:
> >>>>>
> >>>>> 1. IIUC, there is a button on machine which supports hot-remove memory,
> >>>>> then what's the difference between press button and echo to /sys?
> >>>>
> >>>> No important difference, I think. Since I don't have the machine you are
> >>>> saying, I cannot surely answer you. :)
> >>>> AFAIK, pressing the button means trigger the hotplug from hardware, sysfs
> >>>> is just another entrance. At last, they will run into the same code.
> >>>>
> >>>>> 2. Since kernel memory is linear mapping(I mean direct mapping part),
> >>>>> why can't put kernel direct mapping memory into one memory device, and
> >>>>> other memory into the other devices?
> >>>>
> >>>> We cannot do that because in that way, we will lose NUMA performance.
> >>>>
> >>>> If you know NUMA, you will understand the following example:
> >>>>
> >>>> node0: node1:
> >>>> cpu0~cpu15 cpu16~cpu31
> >>>> memory0~memory511 memory512~memory1023
> >>>>
> >>>> cpu16~cpu31 access memory16~memory1023 much faster than memory0~memory511.
> >>>> If we set direct mapping area in node0, and movable area in node1, then
> >>>> the kernel code running on cpu16~cpu31 will have to access
> >>>> memory0~memory511.
> >>>> This is a terrible performance down.
> >>>
> >>> So if config NUMA, kernel memory will not be linear mapping anymore? For
> >>> example,
> >>>
> >>> Node 0 Node 1
> >>>
> >>> 0 ~ 10G 11G~14G
> >>>
> >>> kernel memory only at Node 0? Can part of kernel memory also at Node 1?
> >>>
> >>> How big is kernel direct mapping memory in x86_64? Is there max limit?
> >>
> >>
> >> Max kernel direct mapping memory in x86_64 is 64TB.
> >
> > For example, I have 8G memory, all of them will be direct mapping for
> > kernel? then userspace memory allocated from where?
>
> Direct mapping memory means you can use __va() and pa(), but not means that them
> can be only used by kernel, them can be used by user-space too, as long as them are free.
IIUC, the benefit of va() and pa() is just for quick get
virtual/physical address, it takes advantage of linear mapping. But mmu
still need to go through pgd/pud/pmd/pte, correct?
>
> >
> >>
> >>> It seems that only around 896MB on x86_32.
> >>>
> >>>>
> >>>>> As you know x86_64 don't need
> >>>>> highmem, IIUC, all kernel memory will linear mapping in this case. Is my
> >>>>> idea available? If is correct, x86_32 can't implement in the same way
> >>>>> since highmem(kmap/kmap_atomic/vmalloc) can map any address, so it's
> >>>>> hard to focus kernel memory on single memory device.
> >>>>
> >>>> Sorry, I'm not quite familiar with x86_32 box.
> >>>>
> >>>>> 3. In current implementation, if memory hotplug just need memory
> >>>>> subsystem and ACPI codes support? Or also needs firmware take part in?
> >>>>> Hope you can explain in details, thanks in advance. :)
> >>>>
> >>>> We need firmware take part in, such as SRAT in ACPI BIOS, or the firmware
> >>>> based memory migration mentioned by Liu Jiang.
> >>>
> >>> Is there any material about firmware based memory migration?
> >>>
> >>>>
> >>>> So far, I only know this. :)
> >>>>
> >>>>> 4. What's the status of memory hotplug? Apart from can't remove kernel
> >>>>> memory, other things are fully implementation?
> >>>>
> >>>> I think the main job is done for now. And there are still bugs to fix.
> >>>> And this functionality is not stable.
> >>>>
> >>>> Thanks. :)
> >>>
> >>>
> >>> --
> >>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> >>> the body to majordomo@kvack.org. For more info on Linux MM,
> >>> see: http://www.linux-mm.org/ .
> >>> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
> >>>
> >>> .
> >>>
> >>
> >>
> >>
> >
> >
> >
> > .
> >
>
>
>
^ permalink raw reply
* Re: [PATCH v6 00/15] memory-hotplug: hot-remove physical memory
From: Jianguo Wu @ 2013-02-01 1:57 UTC (permalink / raw)
To: Simon Jeons
Cc: linux-ia64, linux-sh, Tang Chen, linux-mm, paulus, hpa,
sparclinux, cl, linux-s390, x86, linux-acpi, isimatu.yasuaki,
linfeng, mgorman, kosaki.motohiro, rientjes, len.brown, wency,
cmetcalf, glommer, yinghai, laijs, linux-kernel, minchan.kim,
akpm, linuxppc-dev
In-Reply-To: <1359682576.3574.1.camel@kernel>
On 2013/2/1 9:36, Simon Jeons wrote:
> On Fri, 2013-02-01 at 09:32 +0800, Jianguo Wu wrote:
>> On 2013/1/31 18:38, Simon Jeons wrote:
>>
>>> Hi Tang,
>>> On Thu, 2013-01-31 at 17:44 +0800, Tang Chen wrote:
>>>> Hi Simon,
>>>>
>>>> On 01/31/2013 04:48 PM, Simon Jeons wrote:
>>>>> Hi Tang,
>>>>> On Thu, 2013-01-31 at 15:10 +0800, Tang Chen wrote:
>>>>>
>>>>> 1. IIUC, there is a button on machine which supports hot-remove memory,
>>>>> then what's the difference between press button and echo to /sys?
>>>>
>>>> No important difference, I think. Since I don't have the machine you are
>>>> saying, I cannot surely answer you. :)
>>>> AFAIK, pressing the button means trigger the hotplug from hardware, sysfs
>>>> is just another entrance. At last, they will run into the same code.
>>>>
>>>>> 2. Since kernel memory is linear mapping(I mean direct mapping part),
>>>>> why can't put kernel direct mapping memory into one memory device, and
>>>>> other memory into the other devices?
>>>>
>>>> We cannot do that because in that way, we will lose NUMA performance.
>>>>
>>>> If you know NUMA, you will understand the following example:
>>>>
>>>> node0: node1:
>>>> cpu0~cpu15 cpu16~cpu31
>>>> memory0~memory511 memory512~memory1023
>>>>
>>>> cpu16~cpu31 access memory16~memory1023 much faster than memory0~memory511.
>>>> If we set direct mapping area in node0, and movable area in node1, then
>>>> the kernel code running on cpu16~cpu31 will have to access
>>>> memory0~memory511.
>>>> This is a terrible performance down.
>>>
>>> So if config NUMA, kernel memory will not be linear mapping anymore? For
>>> example,
>>>
>>> Node 0 Node 1
>>>
>>> 0 ~ 10G 11G~14G
>>>
>>> kernel memory only at Node 0? Can part of kernel memory also at Node 1?
>>>
>>> How big is kernel direct mapping memory in x86_64? Is there max limit?
>>
>>
>> Max kernel direct mapping memory in x86_64 is 64TB.
>
> For example, I have 8G memory, all of them will be direct mapping for
> kernel? then userspace memory allocated from where?
Direct mapping memory means you can use __va() and pa(), but not means that them
can be only used by kernel, them can be used by user-space too, as long as them are free.
>
>>
>>> It seems that only around 896MB on x86_32.
>>>
>>>>
>>>>> As you know x86_64 don't need
>>>>> highmem, IIUC, all kernel memory will linear mapping in this case. Is my
>>>>> idea available? If is correct, x86_32 can't implement in the same way
>>>>> since highmem(kmap/kmap_atomic/vmalloc) can map any address, so it's
>>>>> hard to focus kernel memory on single memory device.
>>>>
>>>> Sorry, I'm not quite familiar with x86_32 box.
>>>>
>>>>> 3. In current implementation, if memory hotplug just need memory
>>>>> subsystem and ACPI codes support? Or also needs firmware take part in?
>>>>> Hope you can explain in details, thanks in advance. :)
>>>>
>>>> We need firmware take part in, such as SRAT in ACPI BIOS, or the firmware
>>>> based memory migration mentioned by Liu Jiang.
>>>
>>> Is there any material about firmware based memory migration?
>>>
>>>>
>>>> So far, I only know this. :)
>>>>
>>>>> 4. What's the status of memory hotplug? Apart from can't remove kernel
>>>>> memory, other things are fully implementation?
>>>>
>>>> I think the main job is done for now. And there are still bugs to fix.
>>>> And this functionality is not stable.
>>>>
>>>> Thanks. :)
>>>
>>>
>>> --
>>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>>> the body to majordomo@kvack.org. For more info on Linux MM,
>>> see: http://www.linux-mm.org/ .
>>> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>>>
>>> .
>>>
>>
>>
>>
>
>
>
> .
>
^ permalink raw reply
* Re: [PATCH v6 00/15] memory-hotplug: hot-remove physical memory
From: Tang Chen @ 2013-02-01 1:57 UTC (permalink / raw)
To: Simon Jeons
Cc: linux-ia64, linux-sh, linux-mm, paulus, hpa, sparclinux, cl,
linux-s390, x86, linux-acpi, isimatu.yasuaki, linfeng, mgorman,
kosaki.motohiro, rientjes, len.brown, wency, cmetcalf, glommer,
Jianguo Wu, yinghai, laijs, linux-kernel, minchan.kim, akpm,
linuxppc-dev
In-Reply-To: <1359682576.3574.1.camel@kernel>
On 02/01/2013 09:36 AM, Simon Jeons wrote:
> On Fri, 2013-02-01 at 09:32 +0800, Jianguo Wu wrote:
>>>
>>> So if config NUMA, kernel memory will not be linear mapping anymore? For
>>> example,
>>>
>>> Node 0 Node 1
>>>
>>> 0 ~ 10G 11G~14G
It has nothing to do with linear mapping, I think.
>>>
>>> kernel memory only at Node 0? Can part of kernel memory also at Node 1?
Please refer to find_zone_movable_pfns_for_nodes().
The kernel is not only on node0. It uses all the online nodes evenly. :)
>>>
>>> How big is kernel direct mapping memory in x86_64? Is there max limit?
>>
>>
>> Max kernel direct mapping memory in x86_64 is 64TB.
>
> For example, I have 8G memory, all of them will be direct mapping for
> kernel? then userspace memory allocated from where?
I think you misunderstood what Wu tried to say. :)
The kernel mapped that large space, it doesn't mean it is using that
large space.
The mapping is to make kernel be able to access all the memory, not for
the kernel
to use only. User space can also use the memory, but each process has
its own mapping.
For example:
64TB, what ever
xxxTB, what ever
logic address space: |_____kernel_______|_________user_________________|
\ \ / /
\ /\ /
physical address space: |___\/__\/_____________| 4GB or
8GB, what ever
*****
The ***** part physical is mapped to user space in the process' own
pagetable.
It is also direct mapped in kernel's pagetable. So the kernel can also
access it. :)
>
>>
>>> It seems that only around 896MB on x86_32.
>>>
>>>>
>>>> We need firmware take part in, such as SRAT in ACPI BIOS, or the firmware
>>>> based memory migration mentioned by Liu Jiang.
>>>
>>> Is there any material about firmware based memory migration?
No, I don't have any because this is a functionality of machine from HUAWEI.
I think you can ask Liu Jiang or Wu Jianguo to share some with you. :)
Thanks. :)
^ permalink raw reply
* Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
From: Toshi Kani @ 2013-02-01 1:32 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: linux-s390, jiang.liu, wency, linux-acpi, Greg KH, linux-kernel,
linux-mm, isimatu.yasuaki, yinghai, srivatsa.bhat, guohanjun,
bhelgaas, akpm, linuxppc-dev, lenb
In-Reply-To: <9860755.q4y3PrCFZx@vostro.rjw.lan>
On Thu, 2013-01-31 at 21:54 +0100, Rafael J. Wysocki wrote:
> On Wednesday, January 30, 2013 07:57:45 PM Toshi Kani wrote:
> > On Tue, 2013-01-29 at 23:58 -0500, Greg KH wrote:
> > > On Thu, Jan 10, 2013 at 04:40:19PM -0700, Toshi Kani wrote:
:
> > > > +};
> > > > +
> > > > +struct shp_device {
> > > > + struct list_head list;
> > > > + struct device *device;
> > >
> > > No, make it a "real" device, embed the device into it.
> >
> > This device pointer is used to send KOBJ_ONLINE/OFFLINE event during CPU
> > online/offline operation in order to maintain the current behavior. CPU
> > online/offline operation only changes the state of CPU, so its
> > system/cpu device continues to be present before and after an operation.
> > (Whereas, CPU hot-add/delete operation creates or removes a system/cpu
> > device.) So, this "*device" needs to be a pointer to reference an
> > existing device that is to be on-lined/off-lined.
> >
> > > But, again, I'm going to ask why you aren't using the existing cpu /
> > > memory / bridge / node devices that we have in the kernel. Please use
> > > them, or give me a _really_ good reason why they will not work.
> >
> > We cannot use the existing system devices or ACPI devices here. During
> > hot-plug, ACPI handler sets this shp_device info, so that cpu and memory
> > handlers (drivers/cpu.c and mm/memory_hotplug.c) can obtain their target
> > device information in a platform-neutral way. During hot-add, we first
> > creates an ACPI device node (i.e. device under /sys/bus/acpi/devices),
> > but platform-neutral modules cannot use them as they are ACPI-specific.
>
> But suppose we're smart and have ACPI scan handlers that will create
> "physical" device nodes for those devices during the ACPI namespace scan.
> Then, the platform-neutral nodes will be able to bind to those "physical"
> nodes. Moreover, it should be possible to get a hierarchy of device objects
> this way that will reflect all of the dependencies we need to take into
> account during hot-add and hot-remove operations. That may not be what we
> have today, but I don't see any *fundamental* obstacles preventing us from
> using this approach.
I misstated in my previous email. system/cpu device is actually created
by ACPI driver during ACPI scan in case of hot-add. This is done by
acpi_processor_hotadd_init(), which I consider as a hack but can be
done. system/memory device is created in add_memory() by the mm module.
> This is already done for PCI host bridges and platform devices and I don't
> see why we can't do that for the other types of devices too.
>
> The only missing piece I see is a way to handle the "eject" problem, i.e.
> when we try do eject a device at the top of a subtree and need to tear down
> the entire subtree below it, but if that's going to lead to a system crash,
> for example, we want to cancel the eject. It seems to me that we'll need some
> help from the driver core here.
There are three different approaches suggested for system device
hot-plug:
A. Proceed within system device bus scan.
B. Proceed within ACPI bus scan.
C. Proceed with a sequence (as a mini-boot).
Option A uses system devices as tokens, option B uses acpi devices as
tokens, and option C uses resource tables as tokens, for their handlers.
Here is summary of key questions & answers so far. I hope this
clarifies why I am suggesting option 3.
1. What are the system devices?
System devices provide system-wide core computing resources, which are
essential to compose a computer system. System devices are not
connected to any particular standard buses.
2. Why are the system devices special?
The system devices are initialized during early boot-time, by multiple
subsystems, from the boot-up sequence, in pre-defined order. They
provide low-level services to enable other subsystems to come up.
3. Why can't initialize the system devices from the driver structure at
boot?
The driver structure is initialized at the end of the boot sequence and
requires the low-level services from the system devices initialized
beforehand.
4. Why do we need a new common framework?
Sysfs CPU and memory on-lining/off-lining are performed within the CPU
and memory modules. They are common code and do not depend on ACPI.
Therefore, a new common framework is necessary to integrate both
on-lining/off-lining operation and hot-plugging operation of system
devices into a single framework.
5. Why can't do everything with ACPI bus scan?
Software dependency among system devices may not be dictated by the ACPI
hierarchy. For instance, memory should be initialized before CPUs (i.e.
a new cpu may need its local memory), but such ordering cannot be
guaranteed by the ACPI hierarchy. Also, as described in 4,
online/offline operations are independent from ACPI.
Thanks,
-Toshi
^ permalink raw reply
* Re: [PATCH v6 00/15] memory-hotplug: hot-remove physical memory
From: Jianguo Wu @ 2013-02-01 1:32 UTC (permalink / raw)
To: Simon Jeons
Cc: linux-ia64, linux-sh, Tang Chen, linux-mm, paulus, hpa,
sparclinux, cl, linux-s390, x86, linux-acpi, isimatu.yasuaki,
linfeng, mgorman, kosaki.motohiro, rientjes, len.brown, wency,
cmetcalf, glommer, yinghai, laijs, linux-kernel, minchan.kim,
akpm, linuxppc-dev
In-Reply-To: <1359628705.2048.5.camel@kernel>
On 2013/1/31 18:38, Simon Jeons wrote:
> Hi Tang,
> On Thu, 2013-01-31 at 17:44 +0800, Tang Chen wrote:
>> Hi Simon,
>>
>> On 01/31/2013 04:48 PM, Simon Jeons wrote:
>>> Hi Tang,
>>> On Thu, 2013-01-31 at 15:10 +0800, Tang Chen wrote:
>>>
>>> 1. IIUC, there is a button on machine which supports hot-remove memory,
>>> then what's the difference between press button and echo to /sys?
>>
>> No important difference, I think. Since I don't have the machine you are
>> saying, I cannot surely answer you. :)
>> AFAIK, pressing the button means trigger the hotplug from hardware, sysfs
>> is just another entrance. At last, they will run into the same code.
>>
>>> 2. Since kernel memory is linear mapping(I mean direct mapping part),
>>> why can't put kernel direct mapping memory into one memory device, and
>>> other memory into the other devices?
>>
>> We cannot do that because in that way, we will lose NUMA performance.
>>
>> If you know NUMA, you will understand the following example:
>>
>> node0: node1:
>> cpu0~cpu15 cpu16~cpu31
>> memory0~memory511 memory512~memory1023
>>
>> cpu16~cpu31 access memory16~memory1023 much faster than memory0~memory511.
>> If we set direct mapping area in node0, and movable area in node1, then
>> the kernel code running on cpu16~cpu31 will have to access
>> memory0~memory511.
>> This is a terrible performance down.
>
> So if config NUMA, kernel memory will not be linear mapping anymore? For
> example,
>
> Node 0 Node 1
>
> 0 ~ 10G 11G~14G
>
> kernel memory only at Node 0? Can part of kernel memory also at Node 1?
>
> How big is kernel direct mapping memory in x86_64? Is there max limit?
Max kernel direct mapping memory in x86_64 is 64TB.
> It seems that only around 896MB on x86_32.
>
>>
>>> As you know x86_64 don't need
>>> highmem, IIUC, all kernel memory will linear mapping in this case. Is my
>>> idea available? If is correct, x86_32 can't implement in the same way
>>> since highmem(kmap/kmap_atomic/vmalloc) can map any address, so it's
>>> hard to focus kernel memory on single memory device.
>>
>> Sorry, I'm not quite familiar with x86_32 box.
>>
>>> 3. In current implementation, if memory hotplug just need memory
>>> subsystem and ACPI codes support? Or also needs firmware take part in?
>>> Hope you can explain in details, thanks in advance. :)
>>
>> We need firmware take part in, such as SRAT in ACPI BIOS, or the firmware
>> based memory migration mentioned by Liu Jiang.
>
> Is there any material about firmware based memory migration?
>
>>
>> So far, I only know this. :)
>>
>>> 4. What's the status of memory hotplug? Apart from can't remove kernel
>>> memory, other things are fully implementation?
>>
>> I think the main job is done for now. And there are still bugs to fix.
>> And this functionality is not stable.
>>
>> Thanks. :)
>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
> .
>
^ permalink raw reply
* Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
From: Rafael J. Wysocki @ 2013-01-31 20:54 UTC (permalink / raw)
To: Toshi Kani
Cc: linux-s390, jiang.liu, wency, linux-acpi, Greg KH, linux-kernel,
linux-mm, isimatu.yasuaki, yinghai, srivatsa.bhat, guohanjun,
bhelgaas, akpm, linuxppc-dev, lenb
In-Reply-To: <1359601065.15120.156.camel@misato.fc.hp.com>
On Wednesday, January 30, 2013 07:57:45 PM Toshi Kani wrote:
> On Tue, 2013-01-29 at 23:58 -0500, Greg KH wrote:
> > On Thu, Jan 10, 2013 at 04:40:19PM -0700, Toshi Kani wrote:
> > > +/*
> > > + * Hot-plug device information
> > > + */
> >
> > Again, stop it with the "generic" hotplug term here, and everywhere
> > else. You are doing a very _specific_ type of hotplug devices, so spell
> > it out. We've worked hard to hotplug _everything_ in Linux, you are
> > going to confuse a lot of people with this type of terms.
>
> Agreed. I will clarify in all places.
>
> > > +union shp_dev_info {
> > > + struct shp_cpu {
> > > + u32 cpu_id;
> > > + } cpu;
> >
> > What is this? Why not point to the system device for the cpu?
>
> This info is used to on-line a new CPU and create its system/cpu device.
> In other word, a system/cpu device is created as a result of CPU
> hotplug.
>
> > > + struct shp_memory {
> > > + int node;
> > > + u64 start_addr;
> > > + u64 length;
> > > + } mem;
> >
> > Same here, why not point to the system device?
>
> Same as above.
>
> > > + struct shp_hostbridge {
> > > + } hb;
> > > +
> > > + struct shp_node {
> > > + } node;
> >
> > What happened here with these? Empty structures? Huh?
>
> They are place holders for now. PCI bridge hot-plug and node hot-plug
> are still very much work in progress, so I have not integrated them into
> this framework yet.
>
> > > +};
> > > +
> > > +struct shp_device {
> > > + struct list_head list;
> > > + struct device *device;
> >
> > No, make it a "real" device, embed the device into it.
>
> This device pointer is used to send KOBJ_ONLINE/OFFLINE event during CPU
> online/offline operation in order to maintain the current behavior. CPU
> online/offline operation only changes the state of CPU, so its
> system/cpu device continues to be present before and after an operation.
> (Whereas, CPU hot-add/delete operation creates or removes a system/cpu
> device.) So, this "*device" needs to be a pointer to reference an
> existing device that is to be on-lined/off-lined.
>
> > But, again, I'm going to ask why you aren't using the existing cpu /
> > memory / bridge / node devices that we have in the kernel. Please use
> > them, or give me a _really_ good reason why they will not work.
>
> We cannot use the existing system devices or ACPI devices here. During
> hot-plug, ACPI handler sets this shp_device info, so that cpu and memory
> handlers (drivers/cpu.c and mm/memory_hotplug.c) can obtain their target
> device information in a platform-neutral way. During hot-add, we first
> creates an ACPI device node (i.e. device under /sys/bus/acpi/devices),
> but platform-neutral modules cannot use them as they are ACPI-specific.
But suppose we're smart and have ACPI scan handlers that will create
"physical" device nodes for those devices during the ACPI namespace scan.
Then, the platform-neutral nodes will be able to bind to those "physical"
nodes. Moreover, it should be possible to get a hierarchy of device objects
this way that will reflect all of the dependencies we need to take into
account during hot-add and hot-remove operations. That may not be what we
have today, but I don't see any *fundamental* obstacles preventing us from
using this approach.
This is already done for PCI host bridges and platform devices and I don't
see why we can't do that for the other types of devices too.
The only missing piece I see is a way to handle the "eject" problem, i.e.
when we try do eject a device at the top of a subtree and need to tear down
the entire subtree below it, but if that's going to lead to a system crash,
for example, we want to cancel the eject. It seems to me that we'll need some
help from the driver core here.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* [PATCH 22/25] perf: Make EVENT_ATTR global
From: Arnaldo Carvalho de Melo @ 2013-01-31 17:25 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andi Kleen, Peter Zijlstra, Robert Richter, Anton Blanchard,
linux-kernel, Stephane Eranian, Arnaldo Carvalho de Melo,
linuxppc-dev, Ingo Molnar, Paul Mackerras, Sukadev Bhattiprolu,
Jiri Olsa
In-Reply-To: <1359653128-10433-1-git-send-email-acme@infradead.org>
From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Rename EVENT_ATTR() to PMU_EVENT_ATTR() and make it global so it is
available to all architectures.
Further to allow architectures flexibility, have PMU_EVENT_ATTR() pass
in the variable name as a parameter.
Changelog[v2]
- [Jiri Olsa] No need to define PMU_EVENT_PTR()
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Acked-by: Jiri Olsa <jolsa@redhat.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Anton Blanchard <anton@au1.ibm.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: linuxppc-dev@ozlabs.org
Link: http://lkml.kernel.org/r/20130123062422.GC13720@us.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
arch/x86/kernel/cpu/perf_event.c | 13 +++----------
include/linux/perf_event.h | 11 +++++++++++
2 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 6774c17..c0df5ed2 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1310,11 +1310,6 @@ static struct attribute_group x86_pmu_format_group = {
.attrs = NULL,
};
-struct perf_pmu_events_attr {
- struct device_attribute attr;
- u64 id;
-};
-
/*
* Remove all undefined events (x86_pmu.event_map(id) == 0)
* out of events_attr attributes.
@@ -1348,11 +1343,9 @@ static ssize_t events_sysfs_show(struct device *dev, struct device_attribute *at
#define EVENT_VAR(_id) event_attr_##_id
#define EVENT_PTR(_id) &event_attr_##_id.attr.attr
-#define EVENT_ATTR(_name, _id) \
-static struct perf_pmu_events_attr EVENT_VAR(_id) = { \
- .attr = __ATTR(_name, 0444, events_sysfs_show, NULL), \
- .id = PERF_COUNT_HW_##_id, \
-};
+#define EVENT_ATTR(_name, _id) \
+ PMU_EVENT_ATTR(_name, EVENT_VAR(_id), PERF_COUNT_HW_##_id, \
+ events_sysfs_show)
EVENT_ATTR(cpu-cycles, CPU_CYCLES );
EVENT_ATTR(instructions, INSTRUCTIONS );
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 6bfb2faa..42adf01 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -817,6 +817,17 @@ do { \
} while (0)
+struct perf_pmu_events_attr {
+ struct device_attribute attr;
+ u64 id;
+};
+
+#define PMU_EVENT_ATTR(_name, _var, _id, _show) \
+static struct perf_pmu_events_attr _var = { \
+ .attr = __ATTR(_name, 0444, _show, NULL), \
+ .id = _id, \
+};
+
#define PMU_FORMAT_ATTR(_name, _format) \
static ssize_t \
_name##_show(struct device *dev, \
--
1.8.1.1.361.gec3ae6e
^ permalink raw reply related
* [PATCH 21/25] perf/Power7: Use macros to identify perf events
From: Arnaldo Carvalho de Melo @ 2013-01-31 17:25 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andi Kleen, Peter Zijlstra, Robert Richter, Anton Blanchard,
linux-kernel, Stephane Eranian, Arnaldo Carvalho de Melo,
linuxppc-dev, Ingo Molnar, Paul Mackerras, Sukadev Bhattiprolu,
Jiri Olsa
In-Reply-To: <1359653128-10433-1-git-send-email-acme@infradead.org>
From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Define and use macros to identify perf events codes This would make it
easier and more readable when these event codes need to be used in more
than one place.
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Acked-by: Jiri Olsa <jolsa@redhat.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Anton Blanchard <anton@au1.ibm.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: linuxppc-dev@ozlabs.org
Link: http://lkml.kernel.org/r/20130123062353.GB13720@us.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
arch/powerpc/perf/power7-pmu.c | 28 ++++++++++++++++++++--------
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/perf/power7-pmu.c b/arch/powerpc/perf/power7-pmu.c
index 2ee01e3..eebb36d 100644
--- a/arch/powerpc/perf/power7-pmu.c
+++ b/arch/powerpc/perf/power7-pmu.c
@@ -51,6 +51,18 @@
#define MMCR1_PMCSEL_MSK 0xff
/*
+ * Power7 event codes.
+ */
+#define PME_PM_CYC 0x1e
+#define PME_PM_GCT_NOSLOT_CYC 0x100f8
+#define PME_PM_CMPLU_STALL 0x4000a
+#define PME_PM_INST_CMPL 0x2
+#define PME_PM_LD_REF_L1 0xc880
+#define PME_PM_LD_MISS_L1 0x400f0
+#define PME_PM_BRU_FIN 0x10068
+#define PME_PM_BRU_MPRED 0x400f6
+
+/*
* Layout of constraint bits:
* 6666555555555544444444443333333333222222222211111111110000000000
* 3210987654321098765432109876543210987654321098765432109876543210
@@ -307,14 +319,14 @@ static void power7_disable_pmc(unsigned int pmc, unsigned long mmcr[])
}
static int power7_generic_events[] = {
- [PERF_COUNT_HW_CPU_CYCLES] = 0x1e,
- [PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = 0x100f8, /* GCT_NOSLOT_CYC */
- [PERF_COUNT_HW_STALLED_CYCLES_BACKEND] = 0x4000a, /* CMPLU_STALL */
- [PERF_COUNT_HW_INSTRUCTIONS] = 2,
- [PERF_COUNT_HW_CACHE_REFERENCES] = 0xc880, /* LD_REF_L1_LSU*/
- [PERF_COUNT_HW_CACHE_MISSES] = 0x400f0, /* LD_MISS_L1 */
- [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = 0x10068, /* BRU_FIN */
- [PERF_COUNT_HW_BRANCH_MISSES] = 0x400f6, /* BR_MPRED */
+ [PERF_COUNT_HW_CPU_CYCLES] = PME_PM_CYC,
+ [PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = PME_PM_GCT_NOSLOT_CYC,
+ [PERF_COUNT_HW_STALLED_CYCLES_BACKEND] = PME_PM_CMPLU_STALL,
+ [PERF_COUNT_HW_INSTRUCTIONS] = PME_PM_INST_CMPL,
+ [PERF_COUNT_HW_CACHE_REFERENCES] = PME_PM_LD_REF_L1,
+ [PERF_COUNT_HW_CACHE_MISSES] = PME_PM_LD_MISS_L1,
+ [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = PME_PM_BRU_FIN,
+ [PERF_COUNT_HW_BRANCH_MISSES] = PME_PM_BRU_MPRED,
};
#define C(x) PERF_COUNT_HW_CACHE_##x
--
1.8.1.1.361.gec3ae6e
^ permalink raw reply related
* [PATCH 23/25] perf/POWER7: Make generic event translations available in sysfs
From: Arnaldo Carvalho de Melo @ 2013-01-31 17:25 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andi Kleen, Peter Zijlstra, Robert Richter, Anton Blanchard,
linux-kernel, Stephane Eranian, Arnaldo Carvalho de Melo,
linuxppc-dev, Ingo Molnar, Paul Mackerras, Sukadev Bhattiprolu,
Jiri Olsa
In-Reply-To: <1359653128-10433-1-git-send-email-acme@infradead.org>
From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Make the generic perf events in POWER7 available via sysfs.
$ ls /sys/bus/event_source/devices/cpu/events
branch-instructions
branch-misses
cache-misses
cache-references
cpu-cycles
instructions
stalled-cycles-backend
stalled-cycles-frontend
$ cat /sys/bus/event_source/devices/cpu/events/cache-misses
event=0x400f0
This patch is based on commits that implement this functionality on x86.
Eg:
commit a47473939db20e3961b200eb00acf5fcf084d755
Author: Jiri Olsa <jolsa@redhat.com>
Date: Wed Oct 10 14:53:11 2012 +0200
perf/x86: Make hardware event translations available in sysfs
Changelog:[v2]
[Jiri Osla] Drop EVENT_ID() macro since it is only used once.
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Anton Blanchard <anton@au1.ibm.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: linuxppc-dev@ozlabs.org
Link: http://lkml.kernel.org/r/20130123062454.GD13720@us.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
Documentation/ABI/stable/sysfs-devices-cpu-events | 0
arch/powerpc/include/asm/perf_event_server.h | 23 +++++++++++++++
arch/powerpc/perf/core-book3s.c | 12 ++++++++
arch/powerpc/perf/power7-pmu.c | 34 +++++++++++++++++++++++
4 files changed, 69 insertions(+)
create mode 100644 Documentation/ABI/stable/sysfs-devices-cpu-events
diff --git a/Documentation/ABI/stable/sysfs-devices-cpu-events b/Documentation/ABI/stable/sysfs-devices-cpu-events
new file mode 100644
index 0000000..e69de29
diff --git a/arch/powerpc/include/asm/perf_event_server.h b/arch/powerpc/include/asm/perf_event_server.h
index 9710be3..b9b6c55 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -11,6 +11,7 @@
#include <linux/types.h>
#include <asm/hw_irq.h>
+#include <linux/device.h>
#define MAX_HWEVENTS 8
#define MAX_EVENT_ALTERNATIVES 8
@@ -35,6 +36,7 @@ struct power_pmu {
void (*disable_pmc)(unsigned int pmc, unsigned long mmcr[]);
int (*limited_pmc_event)(u64 event_id);
u32 flags;
+ const struct attribute_group **attr_groups;
int n_generic;
int *generic_events;
int (*cache_events)[PERF_COUNT_HW_CACHE_MAX]
@@ -109,3 +111,24 @@ extern unsigned long perf_instruction_pointer(struct pt_regs *regs);
* If an event_id is not subject to the constraint expressed by a particular
* field, then it will have 0 in both the mask and value for that field.
*/
+
+extern ssize_t power_events_sysfs_show(struct device *dev,
+ struct device_attribute *attr, char *page);
+
+/*
+ * EVENT_VAR() is same as PMU_EVENT_VAR with a suffix.
+ *
+ * Having a suffix allows us to have aliases in sysfs - eg: the generic
+ * event 'cpu-cycles' can have two entries in sysfs: 'cpu-cycles' and
+ * 'PM_CYC' where the latter is the name by which the event is known in
+ * POWER CPU specification.
+ */
+#define EVENT_VAR(_id, _suffix) event_attr_##_id##_suffix
+#define EVENT_PTR(_id, _suffix) &EVENT_VAR(_id, _suffix)
+
+#define EVENT_ATTR(_name, _id, _suffix) \
+ PMU_EVENT_ATTR(_name, EVENT_VAR(_id, _suffix), PME_PM_##_id, \
+ power_events_sysfs_show)
+
+#define GENERIC_EVENT_ATTR(_name, _id) EVENT_ATTR(_name, _id, _g)
+#define GENERIC_EVENT_PTR(_id) EVENT_PTR(_id, _g)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index aa2465e..fa476d5 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -1305,6 +1305,16 @@ static int power_pmu_event_idx(struct perf_event *event)
return event->hw.idx;
}
+ssize_t power_events_sysfs_show(struct device *dev,
+ struct device_attribute *attr, char *page)
+{
+ struct perf_pmu_events_attr *pmu_attr;
+
+ pmu_attr = container_of(attr, struct perf_pmu_events_attr, attr);
+
+ return sprintf(page, "event=0x%02llx\n", pmu_attr->id);
+}
+
struct pmu power_pmu = {
.pmu_enable = power_pmu_enable,
.pmu_disable = power_pmu_disable,
@@ -1537,6 +1547,8 @@ int __cpuinit register_power_pmu(struct power_pmu *pmu)
pr_info("%s performance monitor hardware support registered\n",
pmu->name);
+ power_pmu.attr_groups = ppmu->attr_groups;
+
#ifdef MSR_HV
/*
* Use FCHV to ignore kernel events if MSR.HV is set.
diff --git a/arch/powerpc/perf/power7-pmu.c b/arch/powerpc/perf/power7-pmu.c
index eebb36d..269bf24 100644
--- a/arch/powerpc/perf/power7-pmu.c
+++ b/arch/powerpc/perf/power7-pmu.c
@@ -374,6 +374,39 @@ static int power7_cache_events[C(MAX)][C(OP_MAX)][C(RESULT_MAX)] = {
},
};
+
+GENERIC_EVENT_ATTR(cpu-cycles, CYC);
+GENERIC_EVENT_ATTR(stalled-cycles-frontend, GCT_NOSLOT_CYC);
+GENERIC_EVENT_ATTR(stalled-cycles-backend, CMPLU_STALL);
+GENERIC_EVENT_ATTR(instructions, INST_CMPL);
+GENERIC_EVENT_ATTR(cache-references, LD_REF_L1);
+GENERIC_EVENT_ATTR(cache-misses, LD_MISS_L1);
+GENERIC_EVENT_ATTR(branch-instructions, BRU_FIN);
+GENERIC_EVENT_ATTR(branch-misses, BRU_MPRED);
+
+static struct attribute *power7_events_attr[] = {
+ GENERIC_EVENT_PTR(CYC),
+ GENERIC_EVENT_PTR(GCT_NOSLOT_CYC),
+ GENERIC_EVENT_PTR(CMPLU_STALL),
+ GENERIC_EVENT_PTR(INST_CMPL),
+ GENERIC_EVENT_PTR(LD_REF_L1),
+ GENERIC_EVENT_PTR(LD_MISS_L1),
+ GENERIC_EVENT_PTR(BRU_FIN),
+ GENERIC_EVENT_PTR(BRU_MPRED),
+ NULL
+};
+
+
+static struct attribute_group power7_pmu_events_group = {
+ .name = "events",
+ .attrs = power7_events_attr,
+};
+
+static const struct attribute_group *power7_pmu_attr_groups[] = {
+ &power7_pmu_events_group,
+ NULL,
+};
+
static struct power_pmu power7_pmu = {
.name = "POWER7",
.n_counter = 6,
@@ -385,6 +418,7 @@ static struct power_pmu power7_pmu = {
.get_alternatives = power7_get_alternatives,
.disable_pmc = power7_disable_pmc,
.flags = PPMU_ALT_SIPR,
+ .attr_groups = power7_pmu_attr_groups,
.n_generic = ARRAY_SIZE(power7_generic_events),
.generic_events = power7_generic_events,
.cache_events = &power7_cache_events,
--
1.8.1.1.361.gec3ae6e
^ permalink raw reply related
* [GIT PULL 00/25] perf/core improvements and fixes
From: Arnaldo Carvalho de Melo @ 2013-01-31 17:25 UTC (permalink / raw)
To: Ingo Molnar
Cc: Arnaldo Carvalho de Melo, Arnaldo Carvalho de Melo,
Robert Richter, Andi Kleen, Peter Zijlstra, Frederic Weisbecker,
Namhyung Kim, Anton Blanchard, linux-kernel, Stephane Eranian,
Pekka Enberg, linuxppc-dev, Paul Mackerras, Mike Galbraith, acme,
David Ahern, Namhyung Kim, Sukadev Bhattiprolu, Jiri Olsa
Hi Ingo,
Please consider pulling,
- Arnaldo
The following changes since commit 152fefa921535665f95840c08062844ab2f5593e:
Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core (2013-01-31 10:20:14 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux tags/perf-core-for-mingo
for you to fetch changes up to 2ac3634a7e1c8eedc961030c87c5c36ebd5bbf8e:
perf: Document the ABI of perf sysfs entries (2013-01-31 13:07:51 -0300)
----------------------------------------------------------------
perf/core improvements and fixes:
. Make some POWER7 events available in sysfs, equivalent to
what was done on x86, from Sukadev Bhattiprolu.
. Add event group view, from Namyung Kim:
To use it, 'perf record' should group events when recording. And then perf
report parses the saved group relation from file header and prints them
together if --group option is provided. You can use 'perf evlist' command to
see event group information:
$ perf record -e '{ref-cycles,cycles}' noploop 1
[ perf record: Woken up 2 times to write data ]
[ perf record: Captured and wrote 0.385 MB perf.data (~16807 samples) ]
$ perf evlist --group
{ref-cycles,cycles}
With this example, default perf report will show you each event
separately like this:
$ perf report
...
# group: {ref-cycles,cycles}
# ========
# Samples: 3K of event 'ref-cycles'
# Event count (approx.): 3153797218
#
# Overhead Command Shared Object Symbol
# ........ ....... ................. ..........................
99.84% noploop noploop [.] main
0.07% noploop ld-2.15.so [.] strcmp
0.03% noploop [kernel.kallsyms] [k] timerqueue_del
0.03% noploop [kernel.kallsyms] [k] sched_clock_cpu
0.02% noploop [kernel.kallsyms] [k] account_user_time
0.01% noploop [kernel.kallsyms] [k] __alloc_pages_nodemask
0.00% noploop [kernel.kallsyms] [k] native_write_msr_safe
# Samples: 3K of event 'cycles'
# Event count (approx.): 3722310525
#
# Overhead Command Shared Object Symbol
# ........ ....... ................. .........................
99.76% noploop noploop [.] main
0.11% noploop [kernel.kallsyms] [k] _raw_spin_lock
0.06% noploop [kernel.kallsyms] [k] find_get_page
0.03% noploop [kernel.kallsyms] [k] sched_clock_cpu
0.02% noploop [kernel.kallsyms] [k] rcu_check_callbacks
0.02% noploop [kernel.kallsyms] [k] __current_kernel_time
0.00% noploop [kernel.kallsyms] [k] native_write_msr_safe
In this case the event group information will be shown in the end of
header area. So you can use --group option to enable event group view.
$ perf report --group
...
# group: {ref-cycles,cycles}
# ========
# Samples: 7K of event 'anon group { ref-cycles, cycles }'
# Event count (approx.): 6876107743
#
# Overhead Command Shared Object Symbol
# ................ ....... ................. ..........................
99.84% 99.76% noploop noploop [.] main
0.07% 0.00% noploop ld-2.15.so [.] strcmp
0.03% 0.00% noploop [kernel.kallsyms] [k] timerqueue_del
0.03% 0.03% noploop [kernel.kallsyms] [k] sched_clock_cpu
0.02% 0.00% noploop [kernel.kallsyms] [k] account_user_time
0.01% 0.00% noploop [kernel.kallsyms] [k] __alloc_pages_nodemask
0.00% 0.00% noploop [kernel.kallsyms] [k] native_write_msr_safe
0.00% 0.11% noploop [kernel.kallsyms] [k] _raw_spin_lock
0.00% 0.06% noploop [kernel.kallsyms] [k] find_get_page
0.00% 0.02% noploop [kernel.kallsyms] [k] rcu_check_callbacks
0.00% 0.02% noploop [kernel.kallsyms] [k] __current_kernel_time
As you can see the Overhead column now contains both of ref-cycles and
cycles and header line shows group information also - 'anon group {
ref-cycles, cycles }'. The output is sorted by period of group leader
first.
If perf.data file doesn't contain group information, this --group
option does nothing. So if you want enable event group view by
default you can set it in ~/.perfconfig file:
$ cat ~/.perfconfig
[report]
group = true
It can be overridden with command line if you want:
$ perf report --no-group
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
----------------------------------------------------------------
Arnaldo Carvalho de Melo (2):
perf top: Stop using exit()
perf top: Delete maps on exit
Namhyung Kim (18):
perf tools: Keep group information
perf tests: Add group test conditions
perf header: Add HEADER_GROUP_DESC feature
perf report: Make another loop for linking group hists
perf hists: Resort hist entries using group members for output
perf ui/hist: Consolidate hpp helpers
perf hists browser: Convert hpp helpers to a function
perf gtk/browser: Convert hpp helpers to a function
perf ui/hist: Add support for event group view
perf hists browser: Move coloring logic to hpp functions
perf hists browser: Add suppport for event group view
perf gtk/browser: Add support for event group view
perf gtk/browser: Trim column header string when event group enabled
perf report: Bypass non-leader events when event group is enabled
perf report: Show group description when event group is enabled
perf report: Add --group option
perf report: Add report.group config option
perf evlist: Add --group option
Sukadev Bhattiprolu (5):
perf/Power7: Use macros to identify perf events
perf: Make EVENT_ATTR global
perf/POWER7: Make generic event translations available in sysfs
perf/POWER7: Make some POWER7 events available in sysfs
perf: Document the ABI of perf sysfs entries
.../testing/sysfs-bus-event_source-devices-events | 62 +++++
arch/powerpc/include/asm/perf_event_server.h | 26 ++
arch/powerpc/perf/core-book3s.c | 12 +
arch/powerpc/perf/power7-pmu.c | 80 +++++-
arch/x86/kernel/cpu/perf_event.c | 13 +-
include/linux/perf_event.h | 11 +
tools/perf/Documentation/perf-evlist.txt | 4 +
tools/perf/Documentation/perf-report.txt | 3 +
tools/perf/builtin-evlist.c | 7 +
tools/perf/builtin-record.c | 3 +
tools/perf/builtin-report.c | 47 +++-
tools/perf/builtin-top.c | 62 +++--
tools/perf/tests/parse-events.c | 28 ++
tools/perf/ui/browsers/hists.c | 217 ++++++++++++---
tools/perf/ui/gtk/hists.c | 130 +++++++--
tools/perf/ui/hist.c | 306 ++++++++++-----------
tools/perf/ui/stdio/hist.c | 2 +
tools/perf/util/evlist.c | 7 +-
tools/perf/util/evlist.h | 1 +
tools/perf/util/evsel.c | 49 +++-
tools/perf/util/evsel.h | 16 ++
tools/perf/util/header.c | 164 +++++++++++
tools/perf/util/header.h | 2 +
tools/perf/util/hist.c | 59 +++-
tools/perf/util/parse-events.c | 1 +
tools/perf/util/parse-events.h | 1 +
tools/perf/util/parse-events.y | 10 +
tools/perf/util/symbol.h | 3 +-
28 files changed, 1059 insertions(+), 267 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-event_source-devices-events
^ permalink raw reply
* [PATCH 25/25] perf: Document the ABI of perf sysfs entries
From: Arnaldo Carvalho de Melo @ 2013-01-31 17:25 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andi Kleen, Peter Zijlstra, Robert Richter, Anton Blanchard,
linux-kernel, Stephane Eranian, Arnaldo Carvalho de Melo,
linuxppc-dev, Ingo Molnar, Paul Mackerras, Sukadev Bhattiprolu,
Jiri Olsa
In-Reply-To: <1359653128-10433-1-git-send-email-acme@infradead.org>
From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
This patchset addes two new sets of files to sysfs for POWER architecture.
- perf event config format in /sys/devices/cpu/format/event
- generic and POWER-specific perf events in /sys/devices/cpu/events/
The format of the first file is already documented in:
sysfs-bus-event_source-devices-format
Document the format of the second set of files '/sys/devices/cpu/events/*'
which would also become part of the ABI.
Changelog[v4]:
[Jiri Olsa]: Mention that multiple event= like terms can be specified
in the 'events' file.
[Jiri Olsa]: Remove the documentation for the 'config format' file
as it is already documented in 'Documentation/ABI/testing/'.
[Jiri Olsa]: Move ABI documentation from 'stable/' to 'testing/'
Changelog[v3]:
[Greg KH] Include ABI documentation.
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Acked-by: Jiri Olsa <jolsa@redhat.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Anton Blanchard <anton@au1.ibm.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: linuxppc-dev@ozlabs.org
Link: http://lkml.kernel.org/r/20130123062645.GG13720@us.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
Documentation/ABI/stable/sysfs-devices-cpu-events | 0
.../testing/sysfs-bus-event_source-devices-events | 62 ++++++++++++++++++++++
2 files changed, 62 insertions(+)
delete mode 100644 Documentation/ABI/stable/sysfs-devices-cpu-events
create mode 100644 Documentation/ABI/testing/sysfs-bus-event_source-devices-events
diff --git a/Documentation/ABI/stable/sysfs-devices-cpu-events b/Documentation/ABI/stable/sysfs-devices-cpu-events
deleted file mode 100644
index e69de29..0000000
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
new file mode 100644
index 0000000..0adeb52
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
@@ -0,0 +1,62 @@
+What: /sys/devices/cpu/events/
+ /sys/devices/cpu/events/branch-misses
+ /sys/devices/cpu/events/cache-references
+ /sys/devices/cpu/events/cache-misses
+ /sys/devices/cpu/events/stalled-cycles-frontend
+ /sys/devices/cpu/events/branch-instructions
+ /sys/devices/cpu/events/stalled-cycles-backend
+ /sys/devices/cpu/events/instructions
+ /sys/devices/cpu/events/cpu-cycles
+
+Date: 2013/01/08
+
+Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
+
+Description: Generic performance monitoring events
+
+ A collection of performance monitoring events that may be
+ supported by many/most CPUs. These events can be monitored
+ using the 'perf(1)' tool.
+
+ The contents of each file would look like:
+
+ event=0xNNNN
+
+ where 'N' is a hex digit and the number '0xNNNN' shows the
+ "raw code" for the perf event identified by the file's
+ "basename".
+
+
+What: /sys/devices/cpu/events/PM_LD_MISS_L1
+ /sys/devices/cpu/events/PM_LD_REF_L1
+ /sys/devices/cpu/events/PM_CYC
+ /sys/devices/cpu/events/PM_BRU_FIN
+ /sys/devices/cpu/events/PM_GCT_NOSLOT_CYC
+ /sys/devices/cpu/events/PM_BRU_MPRED
+ /sys/devices/cpu/events/PM_INST_CMPL
+ /sys/devices/cpu/events/PM_CMPLU_STALL
+
+Date: 2013/01/08
+
+Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
+ Linux Powerpc mailing list <linuxppc-dev@ozlabs.org>
+
+Description: POWER-systems specific performance monitoring events
+
+ A collection of performance monitoring events that may be
+ supported by the POWER CPU. These events can be monitored
+ using the 'perf(1)' tool.
+
+ These events may not be supported by other CPUs.
+
+ The contents of each file would look like:
+
+ event=0xNNNN
+
+ where 'N' is a hex digit and the number '0xNNNN' shows the
+ "raw code" for the perf event identified by the file's
+ "basename".
+
+ Further, multiple terms like 'event=0xNNNN' can be specified
+ and separated with comma. All available terms are defined in
+ the /sys/bus/event_source/devices/<dev>/format file.
--
1.8.1.1.361.gec3ae6e
^ permalink raw reply related
* [PATCH 24/25] perf/POWER7: Make some POWER7 events available in sysfs
From: Arnaldo Carvalho de Melo @ 2013-01-31 17:25 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andi Kleen, Peter Zijlstra, Robert Richter, Anton Blanchard,
linux-kernel, Stephane Eranian, Arnaldo Carvalho de Melo,
linuxppc-dev, Ingo Molnar, Paul Mackerras, Sukadev Bhattiprolu,
Jiri Olsa
In-Reply-To: <1359653128-10433-1-git-send-email-acme@infradead.org>
From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Make some POWER7-specific perf events available in sysfs.
$ /bin/ls -1 /sys/bus/event_source/devices/cpu/events/
branch-instructions
branch-misses
cache-misses
cache-references
cpu-cycles
instructions
PM_BRU_FIN
PM_BRU_MPRED
PM_CMPLU_STALL
PM_CYC
PM_GCT_NOSLOT_CYC
PM_INST_CMPL
PM_LD_MISS_L1
PM_LD_REF_L1
stalled-cycles-backend
stalled-cycles-frontend
where the 'PM_*' events are POWER specific and the others are the
generic events.
This will enable users to specify these events with their symbolic
names rather than with their raw code.
perf stat -e 'cpu/PM_CYC' ...
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Anton Blanchard <anton@au1.ibm.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: linuxppc-dev@ozlabs.org
Link: http://lkml.kernel.org/r/20130123062528.GE13720@us.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
arch/powerpc/include/asm/perf_event_server.h | 3 +++
arch/powerpc/perf/power7-pmu.c | 18 ++++++++++++++++++
2 files changed, 21 insertions(+)
diff --git a/arch/powerpc/include/asm/perf_event_server.h b/arch/powerpc/include/asm/perf_event_server.h
index b9b6c55..b29fcc6 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -132,3 +132,6 @@ extern ssize_t power_events_sysfs_show(struct device *dev,
#define GENERIC_EVENT_ATTR(_name, _id) EVENT_ATTR(_name, _id, _g)
#define GENERIC_EVENT_PTR(_id) EVENT_PTR(_id, _g)
+
+#define POWER_EVENT_ATTR(_name, _id) EVENT_ATTR(PM_##_name, _id, _p)
+#define POWER_EVENT_PTR(_id) EVENT_PTR(_id, _p)
diff --git a/arch/powerpc/perf/power7-pmu.c b/arch/powerpc/perf/power7-pmu.c
index 269bf24..b554879 100644
--- a/arch/powerpc/perf/power7-pmu.c
+++ b/arch/powerpc/perf/power7-pmu.c
@@ -384,6 +384,15 @@ GENERIC_EVENT_ATTR(cache-misses, LD_MISS_L1);
GENERIC_EVENT_ATTR(branch-instructions, BRU_FIN);
GENERIC_EVENT_ATTR(branch-misses, BRU_MPRED);
+POWER_EVENT_ATTR(CYC, CYC);
+POWER_EVENT_ATTR(GCT_NOSLOT_CYC, GCT_NOSLOT_CYC);
+POWER_EVENT_ATTR(CMPLU_STALL, CMPLU_STALL);
+POWER_EVENT_ATTR(INST_CMPL, INST_CMPL);
+POWER_EVENT_ATTR(LD_REF_L1, LD_REF_L1);
+POWER_EVENT_ATTR(LD_MISS_L1, LD_MISS_L1);
+POWER_EVENT_ATTR(BRU_FIN, BRU_FIN)
+POWER_EVENT_ATTR(BRU_MPRED, BRU_MPRED);
+
static struct attribute *power7_events_attr[] = {
GENERIC_EVENT_PTR(CYC),
GENERIC_EVENT_PTR(GCT_NOSLOT_CYC),
@@ -393,6 +402,15 @@ static struct attribute *power7_events_attr[] = {
GENERIC_EVENT_PTR(LD_MISS_L1),
GENERIC_EVENT_PTR(BRU_FIN),
GENERIC_EVENT_PTR(BRU_MPRED),
+
+ POWER_EVENT_PTR(CYC),
+ POWER_EVENT_PTR(GCT_NOSLOT_CYC),
+ POWER_EVENT_PTR(CMPLU_STALL),
+ POWER_EVENT_PTR(INST_CMPL),
+ POWER_EVENT_PTR(LD_REF_L1),
+ POWER_EVENT_PTR(LD_MISS_L1),
+ POWER_EVENT_PTR(BRU_FIN),
+ POWER_EVENT_PTR(BRU_MPRED),
NULL
};
--
1.8.1.1.361.gec3ae6e
^ permalink raw reply related
* Re: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG register initialization earlier
From: Scott Wood @ 2013-01-31 16:48 UTC (permalink / raw)
To: Caraman Mihai Claudiu-B02008
Cc: linuxppc-dev@lists.ozlabs.org, Alexander Graf,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF2F7861@039-SN2MPN1-012.039d.mgd.msft.net>
On 01/31/2013 09:26:20 AM, Caraman Mihai Claudiu-B02008 wrote:
> > -----Original Message-----
> > From: Alexander Graf [mailto:agraf@suse.de]
> > Sent: Thursday, January 31, 2013 4:58 PM
> > To: Caraman Mihai Claudiu-B02008
> > Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> > dev@lists.ozlabs.org
> > Subject: Re: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG register
> > initialization earlier
> >
> >
> > On 31.01.2013, at 15:56, Caraman Mihai Claudiu-B02008 wrote:
> >
> > >> -----Original Message-----
> > >> From: Alexander Graf [mailto:agraf@suse.de]
> > >> Sent: Thursday, January 31, 2013 3:21 PM
> > >> To: Caraman Mihai Claudiu-B02008
> > >> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> > >> dev@lists.ozlabs.org
> > >> Subject: Re: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG =20
> register
> > >> initialization earlier
> > >>
> > >>
> > >> On 30.01.2013, at 14:29, Mihai Caraman wrote:
> > >>
> > >>> VCPU's MMUCFG register initialization should not depend on
> > >> KVM_CAP_SW_TLB
> > >>> ioctl call. Move it earlier into tlb initalization phase.
> > >>
> > >> Quite the contrary. The fact that there is an mfspr() in =20
> e500_mmu.c
> > >> already tells us that the code is broken. The TLB guest code =20
> should
> > only
> > >> depend on input from the SW_TLB configuration. It's completely
> > orthogonal
> > >> to the host capabilities.
> > >
> > > Then we have the same issue for TLBnCFG registers which need to be
> > configured
> > > via SW_TLB ioctl. What is the purpose of guest tlb initalization =20
> in
> > e500_mmu.c
> > > if we rely on SW_TLB?
> >
> > It's to provide a fallback to user space that doesn't implement =20
> SW_TLB
> > configuration yet.
>=20
> Do we have such a case now or is it just hypothetical? For the =20
> fallback we
> need to initialize the MMUCFG register which I intended to say in the =20
> commit
> message.
I don't think we need to support a fallback for e6500, since there's =20
nothing to be backwards compatible with.
As for use case, I don't see us ever supporting the guest being a =20
different CPU than the host. Page sizes probably aren't a problem, but =20
there are other barriers.
The main reasons that TLBnCFG are settable through SW_TLB are:
1. The guest TLB can be enlarged as a performance hack (like in Topaz, =20
though QEMU doesn't currently do this),
2. The legacy default in KVM is based on the e500v1 TLB0 size, which is =20
half of what e500v2/e500mc have, and
3. QEMU needs to know the exact geometry of the TLB so that it can =20
interpret the shared data properly.
#3 seems like a compelling reason here, to avoid silent weirdness if =20
there's a slight mismatch between what QEMU thinks it's modelling and =20
what we're actually running on.
-Scott=
^ permalink raw reply
* RE: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG register initialization earlier
From: Caraman Mihai Claudiu-B02008 @ 2013-01-31 15:26 UTC (permalink / raw)
To: Alexander Graf
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org
In-Reply-To: <6E880F7F-4EA9-44CF-8C8A-E1963988ACCD@suse.de>
> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Thursday, January 31, 2013 4:58 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org
> Subject: Re: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG register
> initialization earlier
>=20
>=20
> On 31.01.2013, at 15:56, Caraman Mihai Claudiu-B02008 wrote:
>=20
> >> -----Original Message-----
> >> From: Alexander Graf [mailto:agraf@suse.de]
> >> Sent: Thursday, January 31, 2013 3:21 PM
> >> To: Caraman Mihai Claudiu-B02008
> >> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> >> dev@lists.ozlabs.org
> >> Subject: Re: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG register
> >> initialization earlier
> >>
> >>
> >> On 30.01.2013, at 14:29, Mihai Caraman wrote:
> >>
> >>> VCPU's MMUCFG register initialization should not depend on
> >> KVM_CAP_SW_TLB
> >>> ioctl call. Move it earlier into tlb initalization phase.
> >>
> >> Quite the contrary. The fact that there is an mfspr() in e500_mmu.c
> >> already tells us that the code is broken. The TLB guest code should
> only
> >> depend on input from the SW_TLB configuration. It's completely
> orthogonal
> >> to the host capabilities.
> >
> > Then we have the same issue for TLBnCFG registers which need to be
> configured
> > via SW_TLB ioctl. What is the purpose of guest tlb initalization in
> e500_mmu.c
> > if we rely on SW_TLB?
>=20
> It's to provide a fallback to user space that doesn't implement SW_TLB
> configuration yet.
Do we have such a case now or is it just hypothetical? For the fallback we
need to initialize the MMUCFG register which I intended to say in the commi=
t
message.
>=20
>=20
> Alex
>=20
^ permalink raw reply
* RE: [PATCH 4/5] KVM: PPC: e500: Emulate EPTCFG register
From: Caraman Mihai Claudiu-B02008 @ 2013-01-31 14:58 UTC (permalink / raw)
To: Alexander Graf
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org
In-Reply-To: <911274D3-9188-45A5-81B0-643F5DB21653@suse.de>
> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Thursday, January 31, 2013 3:31 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org
> Subject: Re: [PATCH 4/5] KVM: PPC: e500: Emulate EPTCFG register
>=20
>=20
> On 30.01.2013, at 14:29, Mihai Caraman wrote:
>=20
> > EPTCFG register defined by E.PT is accessed unconditionally by Linux
> guests
> > in the presence of MAV 2.0. Emulate EPTCFG register now.
> >
> > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> > ---
> > arch/powerpc/include/asm/kvm_host.h | 1 +
> > arch/powerpc/kvm/e500.h | 6 ++++++
> > arch/powerpc/kvm/e500_emulate.c | 9 +++++++++
> > arch/powerpc/kvm/e500_mmu.c | 5 +++++
> > 4 files changed, 21 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/kvm_host.h
> b/arch/powerpc/include/asm/kvm_host.h
> > index 88fcfe6..f480b20 100644
> > --- a/arch/powerpc/include/asm/kvm_host.h
> > +++ b/arch/powerpc/include/asm/kvm_host.h
> > @@ -503,6 +503,7 @@ struct kvm_vcpu_arch {
> > u32 tlbcfg[4];
> > u32 tlbps[4];
> > u32 mmucfg;
> > + u32 eptcfg;
>=20
> This too needs to be settable through SW_TLB.
>=20
> > u32 epr;
> > struct kvmppc_booke_debug_reg dbg_reg;
> > #endif
> > diff --git a/arch/powerpc/kvm/e500.h b/arch/powerpc/kvm/e500.h
> > index b9f76d8..983eb95 100644
> > --- a/arch/powerpc/kvm/e500.h
> > +++ b/arch/powerpc/kvm/e500.h
> > @@ -308,4 +308,10 @@ static inline unsigned int has_mmu_v2(const struct
> kvm_vcpu *vcpu)
> > return ((vcpu->arch.mmucfg & MMUCFG_MAVN) =3D=3D MMUCFG_MAVN_V2);
> > }
> >
> > +static inline unsigned int supports_page_tables(const struct kvm_vcpu
> *vcpu)
>=20
> bool again. Can we generalize this a bit more? How about a small
> framework that allows us to differentiate across e.XX features?=20
I thought you will ask for it :)
-Mike
^ permalink raw reply
* Re: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG register initialization earlier
From: Alexander Graf @ 2013-01-31 14:58 UTC (permalink / raw)
To: Caraman Mihai Claudiu-B02008
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org
In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF2F7733@039-SN2MPN1-012.039d.mgd.msft.net>
On 31.01.2013, at 15:56, Caraman Mihai Claudiu-B02008 wrote:
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf@suse.de]
>> Sent: Thursday, January 31, 2013 3:21 PM
>> To: Caraman Mihai Claudiu-B02008
>> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
>> dev@lists.ozlabs.org
>> Subject: Re: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG register
>> initialization earlier
>>=20
>>=20
>> On 30.01.2013, at 14:29, Mihai Caraman wrote:
>>=20
>>> VCPU's MMUCFG register initialization should not depend on
>> KVM_CAP_SW_TLB
>>> ioctl call. Move it earlier into tlb initalization phase.
>>=20
>> Quite the contrary. The fact that there is an mfspr() in e500_mmu.c
>> already tells us that the code is broken. The TLB guest code should =
only
>> depend on input from the SW_TLB configuration. It's completely =
orthogonal
>> to the host capabilities.
>=20
> Then we have the same issue for TLBnCFG registers which need to be =
configured
> via SW_TLB ioctl. What is the purpose of guest tlb initalization in =
e500_mmu.c
> if we rely on SW_TLB?
It's to provide a fallback to user space that doesn't implement SW_TLB =
configuration yet.
Alex
^ permalink raw reply
* RE: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG register initialization earlier
From: Caraman Mihai Claudiu-B02008 @ 2013-01-31 14:56 UTC (permalink / raw)
To: Alexander Graf
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org
In-Reply-To: <FE5499BE-EC13-47EA-806C-345F7135B677@suse.de>
> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Thursday, January 31, 2013 3:21 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org
> Subject: Re: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG register
> initialization earlier
>=20
>=20
> On 30.01.2013, at 14:29, Mihai Caraman wrote:
>=20
> > VCPU's MMUCFG register initialization should not depend on
> KVM_CAP_SW_TLB
> > ioctl call. Move it earlier into tlb initalization phase.
>=20
> Quite the contrary. The fact that there is an mfspr() in e500_mmu.c
> already tells us that the code is broken. The TLB guest code should only
> depend on input from the SW_TLB configuration. It's completely orthogonal
> to the host capabilities.
Then we have the same issue for TLBnCFG registers which need to be configur=
ed
via SW_TLB ioctl. What is the purpose of guest tlb initalization in e500_mm=
u.c
if we rely on SW_TLB?
-Mike
^ permalink raw reply
* Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
From: Toshi Kani @ 2013-01-31 14:42 UTC (permalink / raw)
To: Greg KH
Cc: linux-s390@vger.kernel.org, jiang.liu@huawei.com,
wency@cn.fujitsu.com, linux-mm@kvack.org, yinghai@kernel.org,
linux-kernel@vger.kernel.org, Rafael J. Wysocki,
linux-acpi@vger.kernel.org, isimatu.yasuaki@jp.fujitsu.com,
srivatsa.bhat@linux.vnet.ibm.com, guohanjun@huawei.com,
bhelgaas@google.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, lenb@kernel.org
In-Reply-To: <20130131052448.GC3228@kroah.com>
On Thu, 2013-01-31 at 05:24 +0000, Greg KH wrote:
> On Wed, Jan 30, 2013 at 06:15:12PM -0700, Toshi Kani wrote:
> > > Please make it a "real" pointer, and not a void *, those shouldn't be
> > > used at all if possible.
> >
> > How about changing the "void *handle" to acpi_dev_node below?
> >
> > struct acpi_dev_node acpi_node;
> >
> > Basically, it has the same challenge as struct device, which uses
> > acpi_dev_node as well. We can add other FW node when needed (just like
> > device also has *of_node).
>
> That sounds good to me.
Great! Thanks Greg,
-Toshi
^ permalink raw reply
* Re: [PATCH 2/5] KVM: PPC: e500: Emulate TLBnPS registers
From: Alexander Graf @ 2013-01-31 13:32 UTC (permalink / raw)
To: Mihai Caraman; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <F796A11A-01C0-4B4E-B4FE-8E88E40DB2CF@suse.de>
On 31.01.2013, at 14:24, Alexander Graf wrote:
>=20
> On 30.01.2013, at 14:29, Mihai Caraman wrote:
>=20
>> Emulate TLBnPS registers which are available in MMU Architecture =
Version
>> (MAV) 2.0.
>>=20
>> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
>> ---
>> arch/powerpc/include/asm/kvm_host.h | 1 +
>> arch/powerpc/kvm/e500.h | 5 +++++
>> arch/powerpc/kvm/e500_emulate.c | 10 ++++++++++
>> arch/powerpc/kvm/e500_mmu.c | 5 +++++
>> 4 files changed, 21 insertions(+), 0 deletions(-)
>>=20
>> diff --git a/arch/powerpc/include/asm/kvm_host.h =
b/arch/powerpc/include/asm/kvm_host.h
>> index 8a72d59..88fcfe6 100644
>> --- a/arch/powerpc/include/asm/kvm_host.h
>> +++ b/arch/powerpc/include/asm/kvm_host.h
>> @@ -501,6 +501,7 @@ struct kvm_vcpu_arch {
>> spinlock_t wdt_lock;
>> struct timer_list wdt_timer;
>> u32 tlbcfg[4];
>> + u32 tlbps[4];
>> u32 mmucfg;
>> u32 epr;
>> struct kvmppc_booke_debug_reg dbg_reg;
>> diff --git a/arch/powerpc/kvm/e500.h b/arch/powerpc/kvm/e500.h
>> index 41cefd4..b9f76d8 100644
>> --- a/arch/powerpc/kvm/e500.h
>> +++ b/arch/powerpc/kvm/e500.h
>> @@ -303,4 +303,9 @@ static inline unsigned int get_tlbmiss_tid(struct =
kvm_vcpu *vcpu)
>> #define get_tlb_sts(gtlbe) (MAS1_TS)
>> #endif /* !BOOKE_HV */
>>=20
>> +static inline unsigned int has_mmu_v2(const struct kvm_vcpu *vcpu)
>=20
> bool. Also rename it to "is_..." then.
In light of the comment I did in a later patch, this too could be =
convert to feature flags.
Alex
^ permalink raw reply
* Re: [PATCH 5/5] KVM: PPC: e500mc: Enable e6500 cores
From: Alexander Graf @ 2013-01-31 13:31 UTC (permalink / raw)
To: Mihai Caraman; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1359552584-17861-6-git-send-email-mihai.caraman@freescale.com>
On 30.01.2013, at 14:29, Mihai Caraman wrote:
> Extend processor compatibility names to e6500 cores.
>
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
Looks good to me.
Reviewed-by: Alexander Graf <agraf@suse.de>
Alex
> ---
> arch/powerpc/kvm/e500mc.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
> index 1f89d26..6c87299 100644
> --- a/arch/powerpc/kvm/e500mc.c
> +++ b/arch/powerpc/kvm/e500mc.c
> @@ -172,6 +172,8 @@ int kvmppc_core_check_processor_compat(void)
> r = 0;
> else if (strcmp(cur_cpu_spec->cpu_name, "e5500") == 0)
> r = 0;
> + else if (strcmp(cur_cpu_spec->cpu_name, "e6500") == 0)
> + r = 0;
> else
> r = -ENOTSUPP;
>
> --
> 1.7.4.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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