On 04/08/2014 10:03 PM, Christoph Lameter wrote:
> On Tue, 8 Apr 2014, Stanislav Kholmanskikh wrote:
>
>> Forgot to mention. This eight-node system has 8k pages, two-node - 4k pages.
>
> So they are not x86? There are some counter races on !x86.
Yes. This is Linux on SPARC.
>
> --
> To unsubscr
Performance_counter01 and performance_counter02 in kernel/performance_counters
actually have tests on perf_event_open system call, so we move these two tests
to syscalls/perf_event_open.
Signed-off-by: Xiaoguang Wang
---
testcases/kernel/Makefile | 1 -
testcases/kerne
Create ltp-perf_event_open.m4 to determine whether struct perf_event_attr is
defined in .
And according to perf_event_open()'s manpage, the official way of knowing
if perf_event_open() support is enabled is checking for the existence
of the file /proc/sys/kernel/perf_event_paranoid, so add this ch
According to perf_event_open()'s manpage, the official way of knowing
if perf_event_open() support is enabled is checking for the existence
of the file /proc/sys/kernel/perf_event_paranoid, so add this check.
According to this perf_event_open API description, rewrite this test.
int perf_event_open
Hi,
On 04/10/2014 01:04 AM, chru...@suse.cz wrote:
>
>> I tried to figure out how papi_avail gets the number of hardware counters,
>> It seems that it just predefines some const values for
>> specific cpus, but I am not very sure, I do not have much time to read the
>> papi_library source code.
On 04/10/2014 01:06 AM, chru...@suse.cz wrote:
> Hi!
>> Ping :-)
> You are in the queue :). I will have a look tomorrow, but I cannot
> promise that the patch will get merged before next release which should
> happen anytime soon.
That's OK, thanks.
Regards
Xiaoguang Wang
>
-
Hi!
> Ping :-)
You are in the queue :). I will have a look tomorrow, but I cannot
promise that the patch will get merged before next release which should
happen anytime soon.
--
Cyril Hrubis
chru...@suse.cz
--
Put Bad D
Hi!
Hi!
> The Number Hardware Counters is 7, But according to above ./perf_event_open02
> in RHEL7.0beta, the output is 5.
> Whether two slots in PMU has been used, or the output of papi_avail is not
> correct :-) .
I would guess that these are used by kernel or system for something else.
> I
Hi!
> > Just to make it clear. Are you going to remove it by yourself? Or do you
> > want me to prepare a patch for this?
> >
> > Actually, I would like the first option :)
>
> OK, I will remove them.
And, done.
--
Cyril Hrubis
chru...@suse.cz
Hi!
> >> Thank you very-very much.
> >>
> >> It's not bad that we included GET_UNUSED* in LTP. Maybe somebody someday
> >> will need it for their purposes... :)
> >>
> >
> > I'm personaly for removing any unused code because
> >
> > * you may readd it later when needed because it's in the git his
On 04/09/2014 05:08 PM, chru...@suse.cz wrote:
> Hi!
>>
>> Thank you very-very much.
>>
>> It's not bad that we included GET_UNUSED* in LTP. Maybe somebody someday
>> will need it for their purposes... :)
>>
>
> I'm personaly for removing any unused code because
>
> * you may readd it later whe
Hi!
>
> Thank you very-very much.
>
> It's not bad that we included GET_UNUSED* in LTP. Maybe somebody someday
> will need it for their purposes... :)
>
I'm personaly for removing any unused code because
* you may readd it later when needed because it's in the git history
* there is a price
Hi!
> POSIX doesn't state that if mmap() is given only PROT_WRITE, then
> that memory region will have read access too. It's an implementation
> issue of the platform.
>
> On a platform which don't imply read access when only PROT_WRITE is given,
> such a situation happens:
> 1) a child process
Hi!
> This function looks OK for one testcase that needs to check for
> OR logic between flags. I was thinking, whether we should change
> this function to return number matched flags. That way we could
> also check easily for AND logic (matches all flags) if we need
> that in future.
I was going
On Tue, 8 Apr 2014, Stanislav Kholmanskikh wrote:
> Forgot to mention. This eight-node system has 8k pages, two-node - 4k pages.
So they are not x86? There are some counter races on !x86.
--
Put Bad Developers to Shame
Hi Peter/Naresh,
good news!!
After Applying the gcov 4.7 patches on kernel/gcov, and enabled CONFIG_GCOV_FORMAT_4_7 the issue with gcno is resolved.
so it was due to the version incompatibility as you told.
now while running "lcov -c -o coverage.info", this runs for ~5 minutes without any i
On Tue, 8 Apr 2014, Stanislav Kholmanskikh wrote:
> On a two-node system it prints:
> 1: 294
..
> 20: 294
>
> i.e. everything is ok.
>
> But on an eight-node system:
> 1: 173
> 2: 0
> 3: 0
> 4: 173
> 5: 173
> So in general we can't rely on stat_interval value. Correct?
Owww... This could have
On 09.04.2014 11:18, shinto.j...@smartplayin.com wrote:
> now while running "lcov -c -o coverage.info", this runs for ~5 minutes
> without any issues and then is stuck at this below*red *point for long
> time and never exits.
>
> So i did ctrl-C and tried the "genhtml coverage.info -o out" and it
- Original Message -
> From: "gux fnst"
> To: ltp-list@lists.sourceforge.net
> Sent: Wednesday, 9 April, 2014 5:46:34 AM
> Subject: [LTP] [PATCH v3] lib/tst_path_has_mnt_flags.c: create a function
> tst_path_has_mnt_flags()
>
> Create a function tst_path_has_mnt_flags() for checking
Ping :-)
Regards,
Xiaoguang Wang
On 03/21/2014 07:44 PM, Xiaoguang Wang wrote:
> Create misc.sh to place miscellaneous functions, which will be
> useful for tests written in shell but do not have a proper place
> to place.
>
> Currenly add tst_fs_has_free(), which will check if the mounted
> file
Hi,
On 04/01/2014 07:58 PM, chru...@suse.cz wrote:
> Hi!
Make performance_counter01 run default. This performance_counter01 case
is to use perf_event_open() to test hardware CPU events.
Do not let performance_counter02 run defalult. This test need to know
an upper bound on
21 matches
Mail list logo
