until further down within compilation
phases on architectures with variable instruction size like x86. If we
have guarantees that the guessed size of each instruction is an upper
bound on the instruction size, this could probably work though.
Thoughts ?
Thanks,
Mathieu
--
Mathieu Des
* Linus Torvalds (torva...@linux-foundation.org) wrote:
> On Mon, Aug 5, 2013 at 12:54 PM, Mathieu Desnoyers
> wrote:
> >
> > I remember that choosing between 2 and 5 bytes nop in the asm goto was
> > tricky: it had something to do with the fact that gcc doesn't kn
* Steven Rostedt (rost...@goodmis.org) wrote:
> On Mon, 2013-08-05 at 17:28 -0400, Mathieu Desnoyers wrote:
>
[...]
> > My though is that the code above does not cover all jump encodings that
> > can be generated by past, current and future x86 assemblers.
> >
> >
* H. Peter Anvin (h...@linux.intel.com) wrote:
> On 08/05/2013 02:28 PM, Mathieu Desnoyers wrote:
> > * Linus Torvalds (torva...@linux-foundation.org) wrote:
> >> On Mon, Aug 5, 2013 at 12:54 PM, Mathieu Desnoyers
> >> wrote:
> >>>
> >>> I reme
how many important sites, insn cache-wise, are being
shrinked by this approach.
Thanks,
Mathieu
>
> -- Steve
>
>
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
roversial, and I'll be posting them for 3.12 soon.
>
> After that, I'll post the updated patches that have the conversion as
> well as the counter, for RFC and for others to play with.
>
> -- Steve
>
>
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- Original Message -
> From: "Richard Henderson"
> To: "Peter Zijlstra" , "Mathieu Desnoyers"
>
> Cc: "Will Deacon" , linux-ker...@vger.kernel.org,
> "Catalin Marinas" ,
> lttng-...@lists.lttng.org, "Natha
- Original Message -
> From: "Mathieu Desnoyers"
> To: "Richard Henderson"
> Cc: "Jakub Jelinek" , gcc@gcc.gnu.org, "Peter Zijlstra"
> , "Catalin Marinas"
> , "Nathan Lynch" ,
> linux-ker...@vger.kernel.
://wiki.linuxplumbersconf.org/2012:scaling
Best Regards,
Mathieu Desnoyers & Paul E. McKenney
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
-cases/bugs that can creep up.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
/60418
[4] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86056
[5] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68622
[6] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86072
[7] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63273
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
race (on C11) but there isn't one on LKMM.
AFAIU, the issue with barriers like "thread fence" is that it creates
implicit hb relationships between various loads/stores to memory which
are typically not relevant to track from a TSAN perspective. Therefore
I suspect the working set of loads/stores that would need to be
tracked by TSAN would become impractically large.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
-fexceptions),
there is a memory leak. Integration with glibc could avoid this issue,
and also help with the longjmp problem, and fix setcontext/swapcontext,
too.
Thanks,
Florian
___
lttng-dev mailing list
lttng-...@lists.lttng.org
https://lists.lttng.o
On 2024-01-15 14:42, Florian Weimer wrote:
* Mathieu Desnoyers:
[...]
General use of lttng should be fine, I think, only the malloc wrapper
has this problem.
The purpose of the nesting counter TLS variable in the malloc wrapper
is to catch situations like this where a global-dynamic TLS
14 matches
Mail list logo
