similar to: RFC: EfficiencySanitizer working set tool

On Wed, Apr 20, 2016 at 2:48 AM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Tue, Apr 19, 2016 at 10:44 PM, Derek Bruening via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Please reference the prior RFC on EfficiencySanitizer. This is one of >> the performance analysis tools we would like to build under the >> EfficiencySanitizer

Thanks for the comment and suggestions. That's a great idea! We actually thought about using each heap object with its type information for more accurate data, and it is definitely in our future plan. However, there are challenges to do so. For example, getting correct type information for each heap object might not be easy, especially for C programs. An application can even use a custom

On Mon, Apr 18, 2016 at 1:36 PM, Craig, Ben via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On 4/17/2016 4:46 PM, Derek Bruening via llvm-dev wrote: > > *Cache fragmentation*: this tool gather data structure field hotness > information, looking for data layout optimization opportunities by grouping > hot fields together to avoid data cache fragmentation. Future

TL;DR: We plan to build a suite of compiler-based dynamic instrumentation tools for analyzing targeted performance problems. These tools will all live under a new "EfficiencySanitizer" (or "esan") sanitizer umbrella, as they will share significant portions of their implementations. ==================== Motivation ==================== Our goal is to build a suite of dynamic

On Thu, Apr 21, 2016 at 1:57 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > ------------------------------ > > *From: *"Qin Zhao" <zhaoqin at google.com> > *To: *"Hal Finkel" <hfinkel at anl.gov> > *Cc: *"Derek Bruening" <bruening at google.com>, > efficiency-sanitizer at google.com, "llvm-dev" <llvm-dev

> > > Will this technology allow us to pinpoint specific accesses that generally > have high latency (i.e. generally are cache misses)? This information is > useful for programmers, and is also useful as an input to loop unrolling, > instruction scheduling, and the like on ooo cores. > Won't hardware performance counter tell you which accesses are delinquent accesses? The

On Tue, Apr 19, 2016 at 11:19 PM, Sean Silva via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Some of this data might be interesting for profile guidance. Are there any > plans there? > > Esan instrumentation is geared toward application level tuning by developers -- the data collected here are not quite 'actionable' by the compiler directly. For instance, struct

Please reference the prior RFC on EfficiencySanitizer. This is one of the performance analysis tools we would like to build under the EfficiencySanitizer umbrella. ==================== Motivation ==================== An application is running sub-optimally if only part of the data brought into the cache is used, which we call cache fragmentation. Knowing the cache fragmentation information

Have you consider naming it `performance sanitizer` instead? I believe that it would be easier to misheard esan with asan, and psan would solve it. Besides, looks like fun! Good luck Piotr 17.04.2016 11:46 PM "Derek Bruening via llvm-dev" <llvm-dev at lists.llvm.org> napisał(a): TL;DR: We plan to build a suite of compiler-based dynamic instrumentation tools for analyzing targeted

----- Original Message ----- > From: "Hal Finkel via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Qin Zhao" <zhaoqin at google.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Friday, April 22, 2016 7:13:38 PM > Subject: Re: [llvm-dev] RFC: EfficiencySanitizer Cache Fragmentation > tool > ----- Original Message -----

On Tue, Apr 19, 2016 at 1:18 PM, Filipe Cabecinhas <filcab at gmail.com> wrote: > Thanks for proposing this. It seems like it might be an interesting > tool for us too. But this proposal seems a bit hand-wavy, and I think > it's missing some crucial info before we start heading this way. > > At least for the tools you are currently starting to implement, it > would be

On Tue, Apr 19, 2016 at 10:18 AM Filipe Cabecinhas via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Sun, Apr 17, 2016 at 10:46 PM, Derek Bruening via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > TL;DR: We plan to build a suite of compiler-based dynamic instrumentation > > tools for analyzing targeted performance problems. These tools will all > >

On 04/20/2016 02:58 PM, Renato Golin via llvm-dev wrote: > Hi Derek, > > I'm not an expert in any of these topics, but I'm excited that you > guys are doing it. It seems like a missing piece that needs to be > filled. > > Some comments inline... > > > On 17 April 2016 at 22:46, Derek Bruening via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >>

Hello llvmdev, I would like to propose and discuss yet another dynamic tool, which we call MemorySanitizer (msan). The main goal of the tool is to detect uses of uninitialized memory (the major feature of Valgrind/Memcheck not covered by AddressSanitizer). It will also find use-after-destruction-but-before-free in C++. The algorithm of the tool is similar to that of Memcheck (

On Wed, Apr 20, 2016 at 1:42 PM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On 20 April 2016 at 13:18, Yury Gribov <y.gribov at samsung.com> wrote: >> Not when dead store happens in an external DSO where compiler can't detect >> it (same applies for single references). > > Do you mean the ones between the DSO and the instrumented code? >

I've just sent a code review request to llvm-commits. --kcc On Mon, Jun 18, 2012 at 2:39 PM, Kostya Serebryany <kcc at google.com> wrote: > Hello llvmdev, > > I would like to propose and discuss yet another dynamic tool, which we > call MemorySanitizer (msan). > The main goal of the tool is to detect uses of uninitialized memory (the > major feature of

Hi Jeremy, Here's the log with log level 10: https://pastebin.com/0EAuz2B8 The location of the shared folder: /pool/shadowtest The location of the snapshots: /pool/shadowtest/.zfs/snapshot Here are how snapshots are named: autosnap_2019-09-01_13:29:01_daily autosnap_2019-09-01_13:29:01_hourly autosnap_2019-09-01_13:44:09_frequently And this is currently in my smb.conf file: [shadowtest]

Hi there I'm having some troubles with Shadow Copy2 & zfs Snapshots. I have hourly and daily snapshots. If I use the following settings it works (but omits daily snapshots): vfs objects = shadow_copy2 shadow:snapdir = .zfs/snapshot shadow:sort = desc shadow:localtime = yes shadow:format = easysnap-hourly_%Y-%m-%d-%H-%M-UTC However when I try to use the BRE with the prefix,

So I'm trying to get shadow copies to work with Windows clients. The snapshots are being stored at /test/.zfs/snapshot The snapshots are being named like so: autosnap_2019-08-10_21:00:00_frequently autosnap_2019-08-10_21:00:00_monthly autosnap_2019-08-10_22:00:00_hourly This is in my smb.conf: [test] vfs objects = shadow_copy2 shadow:snapdir = /test/.zfs/snapshot shadow:snapprefix =

Greetings, I am trying to use vfs_shadow_copy2 with samba samba-4.2.7. I have a share exported at /export/smb400/. A snapshot of the share is on a separate block device, which is mounted at /export_shadows/volume-00000001/@GMT-2016.02.08-11.48.00/. Samba configuration for the share is: vfs objects = shadow_copy2 shadow:snapdir = /export_shadows/volume-00000001 shadow:fixinodes = yes (Note: I