Re: [Valgrind-users] running valgrind on dpdk

2020-09-29 Thread John Reiser

On 2020-09-29  Prujan, Michael wrote:


I’m running valgrind-3.16.1 on application with DPDK.

I got the following errors:

ERROR: This system does not support "FSGSBASE".


That's correct: the virtual machine that valgrind exports to the app,
does not support FSGSBASE.  The valgrind source says:
./VEX/priv/guest_amd64_helpers.c:/* Don't advertise FSGSBASE 
support, bit 0 in EBX.  */

Perhaps you could develop the support for fsgsbase, and submit the 
implementation patch?


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users


[Valgrind-users] running valgrind on dpdk

2020-09-29 Thread Prujan, Michael
Hi,
I'm running valgrind-3.16.1 on application with DPDK.
I got the following errors:

ERROR: This system does not support "FSGSBASE".
Please check that RTE_MACHINE is set correctly.
EAL: FATAL: unsupported cpu type.
EAL: unsupported cpu type.

However, FSGSBASE exists.
Cat /proc/cpuinfo:

flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est 
tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb 
cat_l3 cdp_l3 intel_pt mba tpr_shadow vnmi flexpriority ept vpid fsgsbase 
tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm mpx rdt_a avx512f 
avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt 
xsavec xgetbv1 cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local ibpb ibrs 
stibp dtherm arat pln pts pku ospke spec_ctrl intel_stibp


I compiled DPDK, without that flag,... application is not running

Thanks,
Michael.



This electronic message may contain proprietary and confidential information of 
Verint Systems Inc., its affiliates and/or subsidiaries. The information is 
intended to be for the use of the individual(s) or entity(ies) named above. If 
you are not the intended recipient (or authorized to receive this e-mail for 
the intended recipient), you may not use, copy, disclose or distribute to 
anyone this message or any information contained in this message. If you have 
received this electronic message in error, please notify us by replying to this 
e-mail.
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users


Re: [Valgrind-users] Partial heap profiling with Massif

2020-09-29 Thread Milian Wolff
On Dienstag, 29. September 2020 12:19:24 CEST LEPAREUR Loic wrote:
> Le 21/09/2020 à 17:04, Milian Wolff a écrit :
> > On Donnerstag, 17. September 2020 15:32:04 CEST John Reiser wrote:
> >> On 2020-09-17 LEPAREUR Loic wrote:
> >>> Several years ago, I developed a Massif patch to let the client code
> >>> select which part of the code should be profiled with Massif.
> >> 
> >> Today this is much less interesting unless you compare and contrast with
> >> https://github.com/KDE/heaptrack .  Do a web search for "heaptrack vs
> >> massif". Consider particularly "A Faster Massif" in
> >> https://milianw.de/tag/heaptrack , and
> >> https://milianw.de/tag/massif-visualizer .
> > 
> > In other news: I just pushed a bunch of patches to heaptrack git which
> > allow you to do time-diffing. I.e. you can now select a time range in the
> > charts and then request filtering to show the delta costs between the two
> > time points.
> > 
> > This should allow you to solve your problem nicely.
> > 
> > Alternatively, you can also runtime-attach heaptrack after you finished
> > your initialization phase to only record the main computational loop. The
> > overhead should be minimal or actually close to zero when your main loop
> > isn't allocating anything.
> > 
> > Cheers
> 
> OK, thanks for pointing that out. I didn't know about it, I will give it
> a try.
> 
> Heaptrack requires recent versions of KChart and Qt for the GUI and it
> isn't easy to upgrade them here.

What do you mean by "recent" - to my knowledge it can build with some-years-
old versions of both ;-)

But even then, you can just download the AppImage and don't need to install 
anything then:

https://download.kde.org/stable/heaptrack/1.2.0/

> And since you LD_PRELOAD Heaptrack, it
> would be very easy to add client requests mechanism, but I will try
> vanilla version first.

Yes, there's already `heaptrack_api.h`, which could be expanded to add support 
for client markers or similar.

Cheers

-- 
Milian Wolff
m...@milianw.de
http://milianw.de

signature.asc
Description: This is a digitally signed message part.
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users


Re: [Valgrind-users] Partial heap profiling with Massif

2020-09-29 Thread LEPAREUR Loic

Le 21/09/2020 à 17:04, Milian Wolff a écrit :

On Donnerstag, 17. September 2020 15:32:04 CEST John Reiser wrote:

On 2020-09-17 LEPAREUR Loic wrote:

Several years ago, I developed a Massif patch to let the client code
select which part of the code should be profiled with Massif.

Today this is much less interesting unless you compare and contrast with
https://github.com/KDE/heaptrack .  Do a web search for "heaptrack vs
massif". Consider particularly "A Faster Massif" in
https://milianw.de/tag/heaptrack , and
https://milianw.de/tag/massif-visualizer .

In other news: I just pushed a bunch of patches to heaptrack git which allow
you to do time-diffing. I.e. you can now select a time range in the charts and
then request filtering to show the delta costs between the two time points.

This should allow you to solve your problem nicely.

Alternatively, you can also runtime-attach heaptrack after you finished your
initialization phase to only record the main computational loop. The overhead
should be minimal or actually close to zero when your main loop isn't
allocating anything.

Cheers

OK, thanks for pointing that out. I didn't know about it, I will give it 
a try.


Heaptrack requires recent versions of KChart and Qt for the GUI and it 
isn't easy to upgrade them here. And since you LD_PRELOAD Heaptrack, it 
would be very easy to add client requests mechanism, but I will try 
vanilla version first.


Cheers




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users