On Fri, May 31, 2024 at 08:09:13AM GMT, Greg KH wrote:
> On Fri, May 31, 2024 at 10:54:58AM +0530, Gautam Menghani wrote:
> > Hello,
> >
> > Please review this patch and let me know if any changes are needed.
>
> There already was review comments on it, why ignore them?
Sorry I pinged on the wro
On Fri, May 31, 2024 at 12:05:48AM -0600, Yu Zhao wrote:
[...]
> All optimizations in v2 were measured step by step. Even that bitmap,
> which might be considered overengineered, brought a readily
> measuarable 4% improvement in memcached throughput on Altra Max
> swapping to Optane:
That's grea
On Wed, May 29, 2024 at 03:03:21PM -0600, Yu Zhao wrote:
> On Wed, May 29, 2024 at 12:05 PM James Houghton wrote:
> >
> > Secondary MMUs are currently consulted for access/age information at
> > eviction time, but before then, we don't get accurate age information.
> > That is, pages that are most
Christoph Hellwig writes:
> On Fri, May 31, 2024 at 12:28:21AM +1000, Michael Ellerman wrote:
>> No that's wrong. The actual hardware page size is 4K, but
>> CONFIG_PAGE_SIZE and PAGE_SHIFT etc. is 64K.
>>
>> So at least for this user the driver used to work with 64K pages, and
>> now doesn't.
>
Michael Ellerman writes:
> Christian Zigotzky writes:
>> On 28.05.24 22:00, Christian Zigotzky wrote:
>>> Hi All,
>>>
>>> Xorg doesn't start anymore since the RC1 of kernel 6.10. We tested it
>>> with the VirtIO GPU and with some Radeon cards.
>>>
>>> Another error message: Failed to start Setup
On 31.05.24 11:03, Michael Ellerman wrote:
> Michael Ellerman writes:
>> Christian Zigotzky writes:
>>> On 28.05.24 22:00, Christian Zigotzky wrote:
Hi All,
Xorg doesn't start anymore since the RC1 of kernel 6.10. We tested it
with the VirtIO GPU and with some Radeon cards.
>
On 5/26/2024 2:35 PM, Borislav Petkov wrote:
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
On Sun, May 26, 2024 at 10:24:41AM +0530, Balasubrmanian, Vignesh wrote:
If we can add a new enum only when we e
https://bugzilla.kernel.org/show_bug.cgi?id=218858
--- Comment #9 from doru iorgulescu (doru.iorgules...@gmail.com) ---
Created attachment 306385
--> https://bugzilla.kernel.org/attachment.cgi?id=306385&action=edit
dmesg-next.txt
--
You may reply to this email to add a comment.
You are receiv
https://bugzilla.kernel.org/show_bug.cgi?id=218858
--- Comment #10 from doru iorgulescu (doru.iorgules...@gmail.com) ---
I have upload dmesg-next.txt
Linux mirela 6.11.0-next-20240529 #2 SMP Fri May 31 09:17:14 EEST 2024 ppc64
GNU/Linux
The problems are the same!
Thank You
Regards
--
You may rep
> On 28 May 2024, at 9:33 AM, Anjali K wrote:
>
> Currently in some cases, when the sampled instruction address register
> latches to a specific address during sampling, the privilege bits captured
> in the sampled event register are incorrect.
> For example, a snippet from the perf report on
On Fri, May 31, 2024 at 11:19:34AM +0200, Thorsten Leemhuis wrote:
> On 31.05.24 11:03, Michael Ellerman wrote:
> > Michael Ellerman writes:
> >> Christian Zigotzky writes:
> >>> On 28.05.24 22:00, Christian Zigotzky wrote:
> Hi All,
>
> Xorg doesn't start anymore since the RC1 of
https://bugzilla.kernel.org/show_bug.cgi?id=218858
--- Comment #11 from doru iorgulescu (doru.iorgules...@gmail.com) ---
Created attachment 306388
--> https://bugzilla.kernel.org/attachment.cgi?id=306388&action=edit
config-next.txt
--
You may reply to this email to add a comment.
You are rece
https://bugzilla.kernel.org/show_bug.cgi?id=218858
--- Comment #12 from doru iorgulescu (doru.iorgules...@gmail.com) ---
I have upload config-next.txt
For Linux Kernel
Linux mirela 6.11.0-next-20240529 #2 SMP Fri May 31 09:17:14 EEST 2024 ppc64
GNU/Linux
The problems are the same!
Thank You
Regard
On Fri, May 31, 2024 at 12:02:15PM +0200, Greg KH wrote:
> On Fri, May 31, 2024 at 11:19:34AM +0200, Thorsten Leemhuis wrote:
> > On 31.05.24 11:03, Michael Ellerman wrote:
> > > Michael Ellerman writes:
> > >> Christian Zigotzky writes:
> > >>> On 28.05.24 22:00, Christian Zigotzky wrote:
> > >>
On 5/23/24 20:22, Krishna Kumar wrote:
>
>
> Hi Oliver,
>
> Thanks for your suggestions. Pls find my response:
>
> On 5/20/24 20:29, Oliver O'Halloran wrote:
>> On Fri, May 17, 2024 at 9:15 PM krishna kumar wrote:
Uh, if I'm reading this right it looks like your "slot" C5 is actually
t
Ok,
I went and worked in tglx's comments. This is what this should look
like.
Only build-tested.
---
>From cf23110f5cc24b6072ba7a26f31cff3ed486e6b3 Mon Sep 17 00:00:00 2001
From: Vignesh Balasubramanian
Date: Tue, 7 May 2024 15:23:31 +0530
Subject: [PATCH] x86/elf: Add a new .note section conta
On Thu, May 16, 2024 at 11:19:54AM -0400, Danny Tsen wrote:
> This patch series provide X25519 support for ppc64le with a new module
> curve25519-ppc64le.
>
> The implementation is based on CRYPTOGAMs perl output from x25519-ppc64.pl.
> (see https://github.com/dot-asm/cryptogams/)
> Modified and a
gcc
hexagon allmodconfig clang
hexagon allyesconfig clang
i386 buildonly-randconfig-001-20240531 clang
i386 buildonly-randconfig-004-20240531 clang
i386 buildonly-randconfig-006-20240531 clang
i386
On 30.05.24 14:51, Michael Ellerman wrote:
Christian Zigotzky writes:
On 28.05.24 22:00, Christian Zigotzky wrote:
Hi All,
Xorg doesn't start anymore since the RC1 of kernel 6.10. We tested it
with the VirtIO GPU and with some Radeon cards.
Another error message: Failed to start Setup Virtua
https://bugzilla.kernel.org/show_bug.cgi?id=218858
--- Comment #13 from Michael Ellerman (mich...@ellerman.id.au) ---
root@mirela:~# lspci -tv
...
-[0001:00]-+-00.0 Apple Inc. CPC945 HT Bridge
...
+-05.0-[03]--+-0d.0 Apple Inc. K2 ATA/100
sr0 ->
../../devices/pci0001:
https://bugzilla.kernel.org/show_bug.cgi?id=218858
--- Comment #14 from doru iorgulescu (doru.iorgules...@gmail.com) ---
Yes is ok with linux-kernel 6.9.3
I can disconect for a test linux kernel 6.10.0-rc1
Thank You
Regards
--
You may reply to this email to add a comment.
You are receiving this
From: "Mark Brown"
Sent: Friday, 17 May, 2024 13:17:20
> On Fri, May 17, 2024 at 05:05:35AM -0400, Elinor Montmasson wrote:
>> From: "Mark Brown"
>> > On Wed, May 15, 2024 at 03:54:09PM +0200, Elinor Montmasson wrote:
>
>> >> + struct clk *cpu_sysclk = clk_get(&pdev->dev, "cpu_sysclk");
From: "Mark Brown"
Sent: Friday, 17 May, 2024 13:06:03
> On Fri, May 17, 2024 at 05:05:38AM -0400, Elinor Montmasson wrote:
>
>> This new compatible is intended to be used when there is no codec
>> device/driver. There is technically no codec device/driver for which
>> the clock input can be set.
From: "Mark Brown"
Sent: Friday, 17 May, 2024 13:11:43
> On Fri, May 17, 2024 at 05:05:41AM -0400, Elinor Montmasson wrote:
>> From: "Mark Brown"
>
>> > This description (and the code) don't feel like they're actually generic
>> > - they're clearly specific to the bidrectional S/PDIF case. I'd
From: "Rob Herring"
Sent: Monday, 20 May, 2024 20:31:48
> On Wed, May 15, 2024 at 03:54:11PM +0200, Elinor Montmasson wrote:
>> Add documentation about new dts bindings following new support
>> for compatible "fsl,imx-audio-generic".
>>
>> Some CPU DAI don't require a real audio codec. The new co
On Fri, May 31, 2024 at 08:46:55AM -0400, Elinor Montmasson wrote:
> From: "Mark Brown"
> > On Fri, May 17, 2024 at 05:05:35AM -0400, Elinor Montmasson wrote:
> >> From: "Mark Brown"
> >> > On Wed, May 15, 2024 at 03:54:09PM +0200, Elinor Montmasson wrote:
> >> >> + struct clk *cpu
On Fri, May 31, 2024 at 08:47:22AM -0400, Elinor Montmasson wrote:
> > When I said "this should use the clock bindings" I meant that we should
> > use the clock bindings for configuration here.
> As far I as know, it's not possible to set the direction with
> the clock bindings, but maybe there i
On Fri, May 31, 2024 at 08:48:04AM -0400, Elinor Montmasson wrote:
> Then maybe it's not be a good idea to make this compatible generic
> for this contribution.
> The original intention is to bring support for the S/PDIF,
> so maybe the contribution should focus on this use case?
> In that case, w
axs101_defconfig gcc
arc defconfig gcc
arc randconfig-001-20240531 gcc
arc randconfig-002-20240531 gcc
armmmp2_defconfig gcc
arm
allnoconfig gcc
arc axs101_defconfig gcc
arc defconfig gcc
arc randconfig-001-20240531 gcc
arc randconfig-002-20240531 gcc
armmmp2_defconfig
https://bugzilla.kernel.org/show_bug.cgi?id=218858
--- Comment #15 from doru iorgulescu (doru.iorgules...@gmail.com) ---
Created attachment 306389
--> https://bugzilla.kernel.org/attachment.cgi?id=306389&action=edit
hdparam-I.txt
--
You may reply to this email to add a comment.
You are receiv
https://bugzilla.kernel.org/show_bug.cgi?id=218858
--- Comment #16 from doru iorgulescu (doru.iorgules...@gmail.com) ---
I have upload hdparam-I.txt
For the cdrom
Is ok with linux kernel 6.9.3
Thank You,
Regards
--
You may reply to this email to add a comment.
You are receiving this mail becaus
On Thu, May 30, 2024 at 07:44:12PM -0500, Nathan Lynch via B4 Relay wrote:
> From: Nathan Lynch
>
> Smatch warns:
>
> arch/powerpc/kernel/rtas.c:1932 __do_sys_rtas() warn: potential
> spectre issue 'args.args' [r] (local cap)
>
> The 'nargs' and 'nret' locals come directly from a user-suppl
On 5/31/24 16:14, Krishna Kumar wrote:
> On 5/23/24 20:22, Krishna Kumar wrote:
>>
>> Hi Oliver,
>>
>> Thanks for your suggestions. Pls find my response:
>>
>> On 5/20/24 20:29, Oliver O'Halloran wrote:
>>> On Fri, May 17, 2024 at 9:15 PM krishna kumar
>>> wrote:
> Uh, if I'm reading this r
/intel-lab-lkp/linux/commits/Andy-Shevchenko/ASoC-codecs-Remove-unused-of_gpio-h/20240531-070350
> base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
> for-next
> patch link:
> https://lore.kernel.org/r/20240530230037.1156253-2-andriy.shevchenko%40linux.intel.co
From: "Mark Brown"
Sent: Friday, 31 May, 2024 15:14:13
> On Fri, May 31, 2024 at 08:48:04AM -0400, Elinor Montmasson wrote:
>
>> Then maybe it's not be a good idea to make this compatible generic
>> for this contribution.
>> The original intention is to bring support for the S/PDIF,
>> so maybe
From: "Mark Brown"
Sent: Friday, 31 May, 2024 15:05:28
> On Fri, May 31, 2024 at 08:46:55AM -0400, Elinor Montmasson wrote:
>> From: "Mark Brown"
>> > On Fri, May 17, 2024 at 05:05:35AM -0400, Elinor Montmasson wrote:
>> >> From: "Mark Brown"
>> >> > On Wed, May 15, 2024 at 03:54:09PM +0200, Eli
The 05/03/2024 14:01, Joey Gouly wrote:
> Implement the PKEYS interface, using the Permission Overlay Extension.
...
> +#ifdef CONFIG_ARCH_HAS_PKEYS
> +int arch_set_user_pkey_access(struct task_struct *tsk, int pkey, unsigned
> long init_val)
> +{
> + u64 new_por = POE_RXW;
> + u64 old_por
allmodconfig gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc axs101_defconfig gcc
arc defconfig gcc
arc randconfig-001-20240531 gcc
arc
gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc axs101_defconfig gcc
arc defconfig gcc
arc randconfig-001-20240531 gcc
arc
On Fri, May 31, 2024 at 01:58:47AM +0300, Andy Shevchenko wrote:
> of_gpio.h is deprecated and subject to remove. The drivers in question
> don't use it, simply remove the unused header.
>
> Signed-off-by: Andy Shevchenko
> ---
> sound/soc/codecs/cs53l30.c| 1 -
Reviewed-by: Charles Keep
Hi Szabolcs,
On Fri, May 31, 2024 at 03:57:07PM +0100, Szabolcs Nagy wrote:
> The 05/03/2024 14:01, Joey Gouly wrote:
> > Implement the PKEYS interface, using the Permission Overlay Extension.
> ...
> > +#ifdef CONFIG_ARCH_HAS_PKEYS
> > +int arch_set_user_pkey_access(struct task_struct *tsk, int p
of_gpio.h is deprecated and subject to remove. The drivers in question
don't use it, simply remove the unused header.
Reviewed-by: Kuninori Morimoto
Reviewed-by: Charles Keepax
Signed-off-by: Andy Shevchenko
---
sound/soc/codecs/ak4118.c| 1 -
sound/soc/codecs/ak4458.c| 1 -
so
of_gpio.h is deprecated and subject to remove.
The driver doesn't use it directly, replace it
with what is really being used.
Signed-off-by: Andy Shevchenko
---
sound/soc/codecs/aw88395/aw88395.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/aw88395/aw88395
Replace or drop the legacy header that is subject to remove.
Not all of them were compile-tested, the series might have
hidden compilation errors.
In v2:
- added tags (Kuninori, Charles)
- ripped out TAS2781 (it's a mess from GPIO handling perspective)
Andy Shevchenko (6):
ASoC: codecs: Remove
of_gpio.h is deprecated and subject to remove. The drivers in question
don't use it, simply remove the unused header.
Signed-off-by: Andy Shevchenko
---
sound/soc/rockchip/rockchip_i2s.c | 1 -
sound/soc/rockchip/rockchip_spdif.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/sound/soc/r
of_gpio.h is deprecated and subject to remove. The drivers in question
don't use it, simply remove the unused header.
Signed-off-by: Andy Shevchenko
---
sound/soc/fsl/imx-es8328.c | 1 -
sound/soc/fsl/imx-rpmsg.c | 2 --
2 files changed, 3 deletions(-)
diff --git a/sound/soc/fsl/imx-es8328.c b
of_gpio.h is deprecated and subject to remove.
The driver doesn't use it directly, replace it
with what is really being used.
Acked-by: Kuninori Morimoto
Signed-off-by: Andy Shevchenko
---
sound/soc/generic/audio-graph-card2-custom-sample.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-
of_gpio.h is deprecated and subject to remove.
The driver doesn't use it directly, replace it
with what is really being used.
Signed-off-by: Andy Shevchenko
---
sound/soc/samsung/aries_wm8994.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/samsung/aries_wm8994.c b
On Fri, May 31, 2024 at 10:48:14AM -0400, Elinor Montmasson wrote:
> From: "Mark Brown"
> > Why not just use the existing compatible - why would someone not want to
> > be able to use the ASRC if it's available in their system?
> That's true but it will be a problem if both `fsl-asoc-card.c` and
The 05/31/2024 16:21, Joey Gouly wrote:
> Hi Szabolcs,
>
> On Fri, May 31, 2024 at 03:57:07PM +0100, Szabolcs Nagy wrote:
> > The 05/03/2024 14:01, Joey Gouly wrote:
> > > Implement the PKEYS interface, using the Permission Overlay Extension.
> > ...
> > > +#ifdef CONFIG_ARCH_HAS_PKEYS
> > > +int
On Tue, May 28, 2024 at 12:26:54PM +0530, Amit Daniel Kachhap wrote:
> On 5/3/24 18:31, Joey Gouly wrote:
> > +#define POE_MAGIC 0x504f4530
> > +struct poe_context {
> > + struct _aarch64_ctx head;
> > + __u64 por_el0;
> > +};
> There is a comment section in the beginning which mentions the
On Wed, 29 May 2024, MarileneGarcia wrote:
> Use __free for device_node values, and thus drop calls to
> of_node_put.
>
> The variable attribute __free adds a scope based cleanup to
> the device node. The goal is to reduce memory management issues
> in the kernel code.
>
> The of_node_put calls
On Fri, May 31, 2024 at 1:03 AM Oliver Upton wrote:
>
> On Fri, May 31, 2024 at 12:05:48AM -0600, Yu Zhao wrote:
Let me add back what I said earlier:
I'm not convinced, but it doesn't mean your point of view is
invalid. If you fully understand the implications of your design
choice and doc
Breno Leitao writes:
> On Thu, May 30, 2024 at 07:44:12PM -0500, Nathan Lynch via B4 Relay wrote:
>> From: Nathan Lynch
>>
>> Smatch warns:
>>
>> arch/powerpc/kernel/rtas.c:1932 __do_sys_rtas() warn: potential
>> spectre issue 'args.args' [r] (local cap)
>>
>> The 'nargs' and 'nret' local
On Fri, May 31, 2024 at 10:48:12AM -0400, Elinor Montmasson wrote:
> From: "Mark Brown"
> > So you're trying to use this as the audio clock? There's no code that
> > enables the clock which seems worrying, and I'd expect that if the
> > device is using it's own clock the device would be querying
On Fri, May 31, 2024 at 11:45:48AM -0500, Nathan Lynch wrote:
> Breno Leitao writes:
>
> > On Thu, May 30, 2024 at 07:44:12PM -0500, Nathan Lynch via B4 Relay wrote:
> >> From: Nathan Lynch
> >> + nargs = array_index_nospec(nargs, ARRAY_SIZE(args.args));
> >> + nret = array_index_nospec(nret,
On Fri, May 31, 2024 at 10:45:04AM -0600, Yu Zhao wrote:
> On Fri, May 31, 2024 at 1:03 AM Oliver Upton wrote:
> >
> > On Fri, May 31, 2024 at 12:05:48AM -0600, Yu Zhao wrote:
>
> Let me add back what I said earlier:
>
> I'm not convinced, but it doesn't mean your point of view is
> invalid.
On Wed, May 29, 2024 at 06:05:09PM +, James Houghton wrote:
[...]
> diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> index 9e2bbee77491..eabb07c66a07 100644
> --- a/arch/arm64/kvm/hyp/pgtable.c
> +++ b/arch/arm64/kvm/hyp/pgtable.c
> @@ -1319,10 +1319,8 @@ static int
On Fri, May 31, 2024 at 12:11:33PM -0700, Oliver Upton wrote:
> On Wed, May 29, 2024 at 06:05:09PM +, James Houghton wrote:
>
> [...]
>
> > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> > index 9e2bbee77491..eabb07c66a07 100644
> > --- a/arch/arm64/kvm/hyp/pgtable
On Fri, May 31, 2024 at 1:24 AM Oliver Upton wrote:
>
> On Wed, May 29, 2024 at 03:03:21PM -0600, Yu Zhao wrote:
> > On Wed, May 29, 2024 at 12:05 PM James Houghton
> > wrote:
> > >
> > > Secondary MMUs are currently consulted for access/age information at
> > > eviction time, but before then, w
On Fri, May 31, 2024 at 1:31 PM Yu Zhao wrote:
>
> On Fri, May 31, 2024 at 1:24 AM Oliver Upton wrote:
> >
> > On Wed, May 29, 2024 at 03:03:21PM -0600, Yu Zhao wrote:
> > > On Wed, May 29, 2024 at 12:05 PM James Houghton
> > > wrote:
> > > >
> > > > Secondary MMUs are currently consulted for a
On Fri, May 31, 2024 at 2:06 PM David Matlack wrote:
>
> On Fri, May 31, 2024 at 1:31 PM Yu Zhao wrote:
> >
> > On Fri, May 31, 2024 at 1:24 AM Oliver Upton wrote:
> > >
> > > On Wed, May 29, 2024 at 03:03:21PM -0600, Yu Zhao wrote:
> > > > On Wed, May 29, 2024 at 12:05 PM James Houghton
> > >
Thanks Herbert.
On 5/31/24 5:20 AM, Herbert Xu wrote:
On Thu, May 16, 2024 at 11:19:54AM -0400, Danny Tsen wrote:
This patch series provide X25519 support for ppc64le with a new module
curve25519-ppc64le.
The implementation is based on CRYPTOGAMs perl output from x25519-ppc64.pl.
(see https:/
On Fri, May 31, 2024 at 02:31:17PM -0600, Yu Zhao wrote:
> On Fri, May 31, 2024 at 1:24 AM Oliver Upton wrote:
[...]
> > Grabbing the MMU lock for write to scan sucks, no argument there. But
> > can you please be specific about the impact of read lock v. RCU in the
> > case of arm64? I had asked
Hi Andy,
kernel test robot noticed the following build errors:
[auto build test ERROR on broonie-sound/for-next]
[also build test ERROR on shawnguo/for-next rockchip/for-next linus/master
v6.10-rc1 next-20240531]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
Use __free for device_node values, and thus drop calls to
of_node_put.
The variable attribute __free adds a scope based cleanup to
the device node. The goal is to reduce memory management issues
in the kernel code.
The of_node_put calls were removed, and the
for_each_available_child_of_node was r
On Wed, May 15, 2024 at 4:06 PM Yu Zhao wrote:
>
> On Wed, May 15, 2024 at 2:45 PM Erhard Furtner wrote:
> >
> > On Wed, 8 May 2024 20:21:11 +0200
> > Erhard Furtner wrote:
> >
> > > Greetings!
> > >
> > > Got that on my dual CPU PowerMac G4 DP shortly after boot. This does not
> > > happen eve
Data type profiling uses instruction tracking by checking each
instruction and updating the register type state in some data
structures. This is useful to find the data type in cases when the
register state gets transferred from one reg to another. Example, in
x86, "mov" instruction and in powerpc,
The patchset from Namhyung added support for data type profiling
in perf tool. This enabled support to associate PMU samples to data
types they refer using DWARF debug information. With the upstream
perf, currently it possible to run perf report or perf annotate to
view the data type information on
Add support to capture and parse raw instruction in powerpc.
Currently, the perf tool infrastructure uses two ways to disassemble
and understand the instruction. One is objdump and other option is
via libcapstone.
Currently, the perf tool infrastructure uses "--no-show-raw-insn" option
with "objdu
Add "update_insn_state" callback to "struct arch" to handle instruction
tracking. Currently updating instruction state is handled by static
function "update_insn_state_x86" which is defined in "annotate-data.c".
Make this as a callback for specific arch and move to archs specific
file "arch/x86/ann
Currently, the perf tool infrastructure disasm_line__parse function to
parse disassembled line.
Example snippet from objdump:
objdump --start-address= --stop-address= -d
--no-show-raw-insn -C
c10224b4: lwz r10,0(r9)
This line "lwz r10,0(r9)" is parsed to extract instruction
perf annotate can be done in different ways. One way is to directly use
"perf annotate" command, other way to annotate specific symbol is to do
"perf report" and press "a" on the sample in UI mode. The approach
preferred in powerpc to parse sample for data type profiling is:
- Read directly from DS
Use the raw instruction code and macros to identify memory instructions,
extract register fields and also offset. The implementation addresses
the D-form, X-form, DS-form instructions. Two main functions are added.
New parse function "load_store__parse" as instruction ops parser for
memory instruct
There are memory instructions in powerpc with opcode as 31.
Example: "ldx RT,RA,RB" , Its X form is as below:
__
| 31 | RT | RA | RB | 21 |/|
--
06 111621 30 31
The opcode for "ldx" i
Data type profiling has concept of instruction tracking.
Example sequence in powerpc:
ld r10,264(r3)
mr r31,r3
<
ld r9,312(r31)
or differently
lwz r10,264(r3)
add r31, r3, RB
lwz r9, 0(r31)
If a sample is hit at
Add few more instructions and use opcode as search key
to find if it is supported by the architecture. Added ones
are: addi, addic, addic., addis, subfic and mulli
Signed-off-by: Athira Rajeev
---
tools/perf/arch/powerpc/annotate/instructions.c | 14 ++
1 file changed, 14 insertions(
Add instruction tracking function "update_insn_state_powerpc" for
powerpc. Example sequence in powerpc:
ld r10,264(r3)
mr r31,r3
<
ld r9,312(r31)
Consider ithe sample is pointing to: "ld r9,312(r31)".
Here the memory reference is hit at "312(r31)" where 312 is the offset
and r31 is
Now perf uses the capstone library to disassemble the instructions in
x86. capstone is used (if available) for perf annotate to speed up.
Currently it only supports x86 architecture. Patch includes changes to
enable this in powerpc. For now, only for data type sort keys, this
method is used and onl
In case of register defined variable (found using
find_data_type_global_reg), if the type of variable happens to be base
type (example, long unsigned int), perf report captures it as:
12.85% long unsigned int long unsigned int +0 (no field)
The above data type is actually referring to sampl
There are cases where define a global register variable and associate it
with a specified register. Example, in powerpc, two registers are
defined to represent variable:
1. r13: represents local_paca
register struct paca_struct *local_paca asm("r13");
2. r1: represents stack_pointer
register void
Since the "ins.name" is not set while using raw instruction,
perf annotate with insn-stat gives wrong data:
Result from "./perf annotate --data-type --insn-stat":
Annotate Instruction stats
total 615, ok 419 (68.1%), bad 196 (31.9%)
Name : Good Bad
-
On Fri, May 31, 2024 at 12:16:50PM +0200, Greg KH wrote:
> On Fri, May 31, 2024 at 12:02:15PM +0200, Greg KH wrote:
> > On Fri, May 31, 2024 at 11:19:34AM +0200, Thorsten Leemhuis wrote:
> > > On 31.05.24 11:03, Michael Ellerman wrote:
> > > > Michael Ellerman writes:
> > > >> Christian Zigotzky
On 01.06.24 08:34, Greg KH wrote:
> On Fri, May 31, 2024 at 12:16:50PM +0200, Greg KH wrote:
>> On Fri, May 31, 2024 at 12:02:15PM +0200, Greg KH wrote:
>>> On Fri, May 31, 2024 at 11:19:34AM +0200, Thorsten Leemhuis wrote:
Thx, I already had an eye on this, but thought tracking would not be
>
85 matches
Mail list logo
