search for: scylladb

...especting --build-id must be taken with a grain of salt unless they were controlled for --build-id. Returning to the original motivation for the investigation (local symbols), we see something interesting. Zooming in r263214 through r263237, we find that the performance characteristics for linking ScyllaDB are substantially different from the others. The reason for this is still unknown. The following commits showed significant performance changes for ScyllaDB. r263222 ~4% speedup for ScyllaDB commit 1ffd121a07a3d67bf52d849c0cdef0f2fad889ba Author: Rafael Espindola <rafael.espindola at gmail.co...

...especting --build-id must be taken with a grain of salt unless they were controlled for --build-id. Returning to the original motivation for the investigation (local symbols), we see something interesting. Zooming in r263214 through r263237, we find that the performance characteristics for linking ScyllaDB are substantially different from the others. The reason for this is still unknown. The following commits showed significant performance changes for ScyllaDB. r263222 ~4% speedup for ScyllaDB commit 1ffd121a07a3d67bf52d849c0cdef0f2fad889ba Author: Rafael Espindola <rafael.espindola at gmail.co...

...; Agreed. We could template functions that call TargetInfo's member functions for each target to eliminate the virtual function calls. > Notice that 1.8% is smaller than the performance variation from r263227 > which is a very innocuous-looking change but caused ~2-3% slowdown for > ScyllaDB (see the thread "LLD performance w.r.t. local symbols (and > --build-id)"). > > -- Sean Silva > > On Wed, Mar 30, 2016 at 3:39 PM, Rui Ueyama via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I was wandering how much is the overhead of virtual funct...

...d be monomorphic and so there shouldn't be much branch-prediction cost (certainly nothing that would cause 1.8% performance delta for the entire link). Notice that 1.8% is smaller than the performance variation from r263227 which is a very innocuous-looking change but caused ~2-3% slowdown for ScyllaDB (see the thread "LLD performance w.r.t. local symbols (and --build-id)"). -- Sean Silva On Wed, Mar 30, 2016 at 3:39 PM, Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I was wandering how much is the overhead of virtual function calls of > TargetInfo member...

I was wandering how much is the overhead of virtual function calls of TargetInfo member functions. TargetInfo handles platform-specific details, and we have target-specific subclasses of that class. The subclasses override functions defined in TargetInfo. The TargetInfo member functions are called multiple times for each relocation. So the cost of virtual function calls may be non-neglible. That

...on...)? We have compiler technologies to address these problems, I think we'd better leave it to them when they can handle it. -- Mehdi > > Notice that 1.8% is smaller than the performance variation from r263227 which is a very innocuous-looking change but caused ~2-3% slowdown for ScyllaDB (see the thread "LLD performance w.r.t. local symbols (and --build-id)"). > > -- Sean Silva > > On Wed, Mar 30, 2016 at 3:39 PM, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > I was wandering how much is the o...

...y this paper: http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/37077.pdf -- Sean Silva > > >> Notice that 1.8% is smaller than the performance variation from r263227 >> which is a very innocuous-looking change but caused ~2-3% slowdown for >> ScyllaDB (see the thread "LLD performance w.r.t. local symbols (and >> --build-id)"). >> >> -- Sean Silva >> >> On Wed, Mar 30, 2016 at 3:39 PM, Rui Ueyama via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> I was wandering how much...

...rcontent.com/media/research.google.com/en//pubs/archive/37077.pdf > > -- Sean Silva > > >> >> >>> Notice that 1.8% is smaller than the performance variation from r263227 >>> which is a very innocuous-looking change but caused ~2-3% slowdown for >>> ScyllaDB (see the thread "LLD performance w.r.t. local symbols (and >>> --build-id)"). >>> >>> -- Sean Silva >>> >>> On Wed, Mar 30, 2016 at 3:39 PM, Rui Ueyama via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> >>&g...

...om/en//pubs/archive/37077.pdf >> >> -- Sean Silva >> >> >>> >>> >>>> Notice that 1.8% is smaller than the performance variation from r263227 >>>> which is a very innocuous-looking change but caused ~2-3% slowdown for >>>> ScyllaDB (see the thread "LLD performance w.r.t. local symbols (and >>>> --build-id)"). >>>> >>>> -- Sean Silva >>>> >>>> On Wed, Mar 30, 2016 at 3:39 PM, Rui Ueyama via llvm-dev < >>>> llvm-dev at lists.llvm.org> wrote:...

...t;> >>> -- Sean Silva >>> >>> >>>> >>>> >>>>> Notice that 1.8% is smaller than the performance variation from r263227 >>>>> which is a very innocuous-looking change but caused ~2-3% slowdown >>>>> for ScyllaDB (see the thread "LLD performance w.r.t. local symbols (and >>>>> --build-id)"). >>>>> >>>>> -- Sean Silva >>>>> >>>>> On Wed, Mar 30, 2016 at 3:39 PM, Rui Ueyama via llvm-dev < >>>>> llvm-dev at l...

Hi everyone out there, I just found out that ssh command doesn't use DIRECT IO to open *.pem, which means private key goes to page cache, which means attacker may exploit meltdown to discover user's private key. I may come up with a POC for that if anybody is interested, I'm basing my work on the tool I created for checking whether system is vulnerable by exploiting MELTDOWN, follow

On Sat, Jan 6, 2018 at 5:38 PM, Philipp Marek <philipp at marek.priv.at> wrote: > I think we are possibly interested in switching to DIRECT IO (given that it >> bypasses any caching system including page cache) when reading *.PEM file >> > Sorry, but this makes no sense. > The data could just as well be read from the SSH process > memory space. > I think