Message-ID: <753a61cb-e331-f91b-a1a9-e2fce2ecba52@linux.ibm.com>
Date:   Tue, 2 Mar 2021 18:08:11 +0100
From:   Thomas Richter <tmricht@...ux.ibm.com>
To:     "Liang, Kan" <kan.liang@...ux.intel.com>,
        linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
        acme@...nel.org
Cc:     svens@...ux.ibm.com, gor@...ux.ibm.com, sumanthk@...ux.ibm.com,
        heiko.carstens@...ibm.com,
        Athira Rajeev <atrajeev@...ux.vnet.ibm.com>
Subject: Re: [PATCH] perf test: Test case 27 fails on s390 and non-x86
 platforms

On 3/2/21 4:23 PM, Liang, Kan wrote:
> 
> 
> On 3/2/2021 9:48 AM, Thomas Richter wrote:
>> On 3/2/21 3:03 PM, Liang, Kan wrote:
>>>
>>> + Athira Rajeev
>>>
>>> On 3/2/2021 8:31 AM, Thomas Richter wrote:
>>>> Executing perf test 27 fails on s390:
>>>>    [root@...lp46 perf]# ./perf test -Fv 27
>>>>    27: Sample parsing
>>>>    --- start ---
>>>>    ---- end ----
>>>>    Sample parsing: FAILED!
>>>>    [root@...lp46 perf]#
>>>>
>>>> The root cause is
>>>> commit c7444297fd3769 ("perf test: Support PERF_SAMPLE_WEIGHT_STRUCT")
>>>> This commit introduced a test case for PERF_SAMPLE_WEIGHT_STRUCT
>>>> but does not adjust non-x86 weak linkage functions.
>>>>
>>>> The error is in test__sample_parsing() --> do_test()
>>>> Function do_test() defines two structures of type struct perf_sample named
>>>> sample and sample_out. The first sets member sample.ins_lat = 117
>>>>
>>>> Structure sample_out is constructed dynamically using functions
>>>> perf_event__synthesize_sample() and evsel__parse_sample().
>>>> Both functions have an x86 specific function version which sets member
>>>> ins_lat. The weak common functions do not set member ins_lat.
>>>>
>>>
>>> I don't think Power supports the instruction latency. As a request from Athira Rajeev, I moved the PERF_SAMPLE_WEIGHT_STRUCT to the X86 specific codes.
>>> https://lore.kernel.org/lkml/D97FEF4F-DD88-4760-885E-9A6161A9B48B@linux.vnet.ibm.com/
>>> https://lore.kernel.org/lkml/1612540912-6562-1-git-send-email-kan.liang@linux.intel.com/
>>>
>>> I don't think we want to add the ins_lat back in the weak common functions.
>>>
>>> Could you please update the perf test and don't apply the PERF_SAMPLE_WEIGHT_STRUCT for the non-X86 platform?
>>
>> I used offical linux git tree
>>   [root@...lp46 perf]# git tag | fgrep 5.12
>> v5.12-rc1
>> [root@...lp46 perf]#
>>
>> So this change is in the pipe. I do not plan to revert individual patches.
> 
> No, we shouldn't revert the patch.
> I mean can you fix the issue in perf test?
> Don't test ins_lat or PERF_SAMPLE_WEIGHT_STRUCT for a non-X86 platform.

That would be very ugly code. We would end up in conditional compiles like
#ifdef __s390x__
#endif
and other architectes like ARM/POWER etc come along. This is something I want to avoid.

And this fix only touches perf, not the kernel.

>>>
>>>
>>>> Later in function samples_same() both data in variable sample and sample_out
>>>> are compared. The comparison fails because sample.ins_lat is 117
>>>> and samples_out.ins_lat is 0, the weak functions never set member ins_lat.
>>>>
>>>> Output after:
>>>>    [root@...lp46 perf]# ./perf test -Fv 27
>>>>    27: Sample parsing
>>>>    --- start ---
>>>>    ---- end ----
>>>>    Sample parsing: Ok
>>>> [root@...lp46 perf]#
>>>>
>>>> Fixes:
>>>> commit c7444297fd3769 ("perf test: Support PERF_SAMPLE_WEIGHT_STRUCT")
>>>
>>> I think the regression should start from
>>> commit fbefe9c2f87f ("perf tools: Support arch specific PERF_SAMPLE_WEIGHT_STRUCT processing")
>>>
>>>
>>> Thanks,
>>> Kan
>>
>> Kan,
>>
>> I do not follow you. Your commit c7444297fd3769d10c7ffb52c81d71503b3e268f
>> adds this line
>>
>> @@ -242,6 +245,7 @@ static int do_test(u64 sample_type, u64 sample_regs, u64 read_format)
>>                  .cgroup         = 114,
>>                  .data_page_size = 115,
>>                  .code_page_size = 116,
>> +               .ins_lat        = 117,
>>
>> And this assignment 117 breaks the test. As mentioned before, member ins_lat is never touched
>> by the weak functions.
>>
> 
> Here is the timeline for the patches.
> 
> 1. The commit c7444297fd3769 and other SPR patches are merged at 2021-02-08. At that time, I don't think we have this issue. perf test should work well.

Nope, that line above 'ins_lat = 117.' breaks the test. Comment it out and it works well!!!
That function do_test() is common code executed on all architectures. Take it out and
it is tested nowhere.

The whole purpose of this test test__sample_parsing() --> do_test() is to convert
a perf_sample structure into the perf_event structure and back again. The test
checks if this convertion works in both directions. See perf_event__synthesize_sample()
which flattens an perf_sample structure named sample into an byte stream. Function
evsel__parse_sample() takes that byte stream and creates a struct perf_sample named
sample_out.
perf_event__synthesize_sample() has as input sample.ins_lat with value 117.
And evsel__parse_sample() creates samples_out with  sample_out.ins_lat value 0.
So the test breaks. Thats why we need to set ins_lat in both functions.

> 2. Athira Rajeev told me that Power doesn't support instruction latency. So I submitted a patch which create weak functions and move the ins_lat into X86 specific.
> 3. The patch (commit fbefe9c2f87f) was finally merged at 2021-02-18. We should observe the perf test at this time.
> 
I just looked at this patch.
As far I as understand the code, the weak functions just set sample member weight and
do not touch member ins_lat. Sample member weight is a 64 bit value. 
It is used when sample_type has bit PERF_SAMPLE_WEIGHT set.

What we need is sample member ins_lat being set. This is the case when sample_type
has bit PERF_SAMPLE_WEIGHT_STRUCT set. On x86 the sample member weight
is split into a lower 32bit value containing weight value and an upper 32 bit
value containing ins_lat value. x86 hardware obviously does not provide larger values.

We need to do the same for non_x86 platforms. Otherwise member ins_lat is never set
and the test fails. Since the weak functions are only called when architecture specific
functions are not available, that hardware is not there to support this. 
So why don't we use this
procedure when we run into the weak functions where is is no hardware support anyway???

> As my understanding, "Fixes" should log the commit where an issue starts to be observed. If someone tries to backport the fix later, they have an idea where to put it.
> 
> Thanks,
> Kan
> 

Thanks Thomas

-- 
Thomas Richter, Dept 3303, IBM s390 Linux Development, Boeblingen, Germany
--
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294

Powered by blists - more mailing lists