Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
From: zhaolei@cn.fujitsu.com (Zhaolei)
Subject: [ltt-dev] Degression from "fix-x86_64-sysenter-trace-race"
Date: Tue, 13 Jan 2009 21:47:31 +0800	[thread overview]
Message-ID: <496C9B73.4010405@cn.fujitsu.com> (raw)
In-Reply-To: <496C49F5.9080300@cn.fujitsu.com>

* Zhaolei Wrote:
> Mathieu Desnoyers Wrote:
>> * Zhaolei (zhaolei at cn.fujitsu.com) wrote:
>>> * Mathieu Desnoyers Wrote:
>>>> * Zhaolei (zhaolei at cn.fujitsu.com) wrote:
>>>>> Hello,
>>>>>
>>>>> I tested lttng's performance by tbench program in x86_64 platform.
>>>>> And I found patch named "fix-x86_64-sysenter-trace-race" makes large
>>>>> degression(about 5%).
>>>>> Here is test result:
>>>>>
>>>>> [----------PATCH----------]                     [TBENCH]
>>>>> lttng-kernel-trace-thread-flag-s390		1317.08
>>>>> lttng-kernel-trace-thread-flag-sh		1315.61
>>>>> lttng-kernel-trace-thread-flag-sparc		1305.02
>>>>> lttng-kernel-trace-thread-flag-sparc64		1314.06
>>>>> lttng-kernel-trace-thread-flag-um		1316.35
>>>>> fix-x86_64-sysenter-trace-race			1250.89
>>>>> lttng-kernel-trace-thread-flag-x86		1259.07
>>>>> lttng-kernel-trace-thread-flag-xtensa		1252.86
>>>>> lttng-kernel-trace-thread-flag-api		1253.35
>>>>> lttng-use-kernel-trace-thread-flag-api		1251.9
>>>>> stringify-support-commas			1247.11
>>>>>
>>>>> And if I remove this patch, degression is not happened:
>>>>> [----------PATCH----------]                     [TBENCH]
>>>>> lttng-kernel-trace-thread-flag-s390		1307.73
>>>>> lttng-kernel-trace-thread-flag-sh		1317.33
>>>>> lttng-kernel-trace-thread-flag-sparc		1306.85
>>>>> lttng-kernel-trace-thread-flag-sparc64		1303.62
>>>>> lttng-kernel-trace-thread-flag-um		1312.08
>>>>> lttng-kernel-trace-thread-flag-x86		1308.5
>>>>> lttng-kernel-trace-thread-flag-xtensa		1310.77
>>>>> lttng-kernel-trace-thread-flag-api		1309.05
>>>>> lttng-use-kernel-trace-thread-flag-api		1310.26
>>>>> stringify-support-commas			1307.69
>>>>>
>>>>> I want to know system's benchmark when lttng turn off,
>>>>> so test environment is following:
>>>>> - Compile kernel with lttng patch up to given one and default config,
>>>>> - Install kernel, Reboot system,
>>>>>   (don't load any lttng module, don't run ltt-arm or lttctl)
>>>>> - Begin tbench test.
>>>>>
>>>>> Plarform is RHEL5.2 root filesystem with linux-2.6.27.7 and lttng-0.60 patchs.
>>>>> Hardware is 4 * Intel(R) Xeon(R) X5260 at 3.33GHz with 4G memory.
>>>>>
>>>>> I think [fix-x86_64-sysenter-trace-race] should not leads so large degression,
>>>>> But I tested several times and result is near.
>>>>>
>>>> Hrm, interesting. Can you give your full kernel .config ? I'd like to
>>>> see if the _TIF_SYSCALL_AUDIT or _TIF_SECCOMP bits are set.
>>> Hello, Mathieu
>>>
>>> kernel config is send as attachment.
>>> I use RHEL's default config with ltt support.
>>>
>> OK, I see that you have 
>>
>> CONFIG_AUDIT=y
>> CONFIG_AUDITSYSCALL=y
>>
>> (therefore _TIF_SYSCALL_AUDIT is probably on)
>>
>> One way we could lessen the impact on your system when tracing is not
>> active is to target more specifically the bit which should be tested at
>> this second test location (when returning to userspace). Can you try
>> changing :
>>
>> sysret_careful:
>>         testl $(_TIF_SYSCALL_TRACE|_TIF_KERNEL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SECCOMP),%edx
>>         jnz ret_from_sys_call_trace
>>
>> (this is after the lttng-instrumentation-x86.patch patch has been
>> applied)
>>
>> for
>>
>> sysret_careful:
>>         testl $_TIF_KERNEL_TRACE,%edx
>>         jnz ret_from_sys_call_trace
>>
>> The logic is that only the _TIF_KERNEL_TRACE thread flag needs to be
>> tested at syscall return because it is the only flag which may be
>> changed concurrently wrt thread execution.
>>
> Hello, Mathieu
> 
> I finished this test, result is following:
> 	[lttng-instrumentation-x86.patc]	[only test _TIF_KERNEL_TRACE]
> step1	1250.55					1301.41
> step2	1255.47					1300.72
> 
> It seems degression is gone when remove _TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SECCOMP check.
> 
> I'll check which flag (_TIF_SYSCALL_TRACE or _TIF_SYSCALL_AUDIT or _TIF_SECCOMP) cause degression.
Hello, Mathieu

Now I finished test.
degression is caused by _TIF_SYSCALL_AUDIT.

Detail is following:
[testl flag]								[Step1]	[Step2]
_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_KERNEL_TRACE|_TIF_SECCOMP	1250.88	1241.51
_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_KERNEL_TRACE			1253.68	1248.58
_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT					1251.53	1247.91
_TIF_SYSCALL_TRACE							1311.41	1312.19
0									1315.96	1295.93

B.R.
Zhaolei

> 
> B.R.
> Zhaolei
> 
>> If we see that this helps, we might want to dig further and try to find
>> a way that would help not having the runtime penality cost even when
>> tracing is enabled.
>>
>> Mathieu
>>
>>
>>> B.R.
>>> Zhaolei
>>>
>>>> If you have a better way to support asynchronously changing the thread
>>>> flags and still have the affected running threads running correctly, I'm
>>>> willing to consider it.
>>>>
>>>> Mathieu
>>>>
>>>>> B.R.
>>>>> Zhaolei
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> ltt-dev mailing list
>>>>> ltt-dev at lists.casi.polymtl.ca
>>>>> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>>>>>
>>> #
>>> # Automatically generated make config: don't edit
>>> # Linux kernel version: 2.6.27.7
>>> # Fri Dec 12 20:32:16 2008
>>> #
>>> CONFIG_64BIT=y
>>> # CONFIG_X86_32 is not set
>>> CONFIG_X86_64=y
>>> CONFIG_X86=y
>>> CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
>>> # CONFIG_GENERIC_LOCKBREAK is not set
>>> CONFIG_GENERIC_TIME=y
>>> CONFIG_GENERIC_CMOS_UPDATE=y
>>> CONFIG_CLOCKSOURCE_WATCHDOG=y
> 






  reply	other threads:[~2009-01-13 13:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-13  1:12 Zhaolei
2009-01-13  2:13 ` Mathieu Desnoyers
2009-01-13  2:56   ` Zhaolei
2009-01-13  2:56     ` Zhaolei
2009-01-13  2:56     ` Zhaolei
2009-01-13  4:24     ` Mathieu Desnoyers
2009-01-13  7:59       ` Zhaolei
2009-01-13 13:47         ` Zhaolei [this message]
2009-01-15  1:41           ` Mathieu Desnoyers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=496C9B73.4010405@cn.fujitsu.com \
    --to=zhaolei@cn.fujitsu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox