search for: hackbench

...IT as with the previous code. An astute observation, I had not considered that. > I presume when you did benchmarking this did not even register? Thought > I wonder if it would if you ran the benchmark for a week or so. You presume I benchmarked :-) I managed to boot something virt and run hackbench in it. I wouldn't know a representative virt setup if I ran into it. The thing is, we want this qspinlock for real hardware because its faster and I really want to avoid having to carry two spinlock implementations -- although I suppose that if we really really have to we could.

...IT as with the previous code. An astute observation, I had not considered that. > I presume when you did benchmarking this did not even register? Thought > I wonder if it would if you ran the benchmark for a week or so. You presume I benchmarked :-) I managed to boot something virt and run hackbench in it. I wouldn't know a representative virt setup if I ran into it. The thing is, we want this qspinlock for real hardware because its faster and I really want to avoid having to carry two spinlock implementations -- although I suppose that if we really really have to we could.

...we can only benefit from removing extra stores. Hot functions in existing benchmarks are probably optimized good enough already, but speeding up the long tail is also important. Also, at least the repro in https://bugs.llvm.org/show_bug.cgi?id=40527 has been extracted from a real kernel benchmark (hackbench), where this extra store costed us 0.45% > > This is on LLVM codebase with -ftrivial-auto-var-init=patter. > > > > As-is it's less than I expected, so I would like to find good benchmark to decide if we should work to make production code from my experiment. > > > &g...

...ng benchmarks are probably optimized good > enough already, but speeding up the long tail is also important. > Also, at least the repro in > https://bugs.llvm.org/show_bug.cgi?id=40527 <https://bugs.llvm.org/show_bug.cgi?id=40527> has been extracted from a > real kernel benchmark (hackbench), where this extra store costed us > 0.45% > > > > This is on LLVM codebase with -ftrivial-auto-var-init=patter. > > > > > > As-is it's less than I expected, so I would like to find good benchmark to decide if we should work to make production code from my expe...

...e probably optimized good >> enough already, but speeding up the long tail is also important. >> Also, at least the repro in >> https://bugs.llvm.org/show_bug.cgi?id=40527 <https://bugs.llvm.org/show_bug.cgi?id=40527> has been extracted from a >> real kernel benchmark (hackbench), where this extra store costed us >> 0.45% >> >> > > This is on LLVM codebase with -ftrivial-auto-var-init=patter. >> > > >> > > As-is it's less than I expected, so I would like to find good benchmark to decide if we should work to make producti...

...t; convoluted and I've no real way to test that but it should be stright fwd to > make work. > > I ran this using the virtme tool (thanks Andy) on my laptop with a 4x > overcommit on vcpus (16 vcpus as compared to the 4 my laptop actually has) and > it both booted and survived a hackbench run (perf bench sched messaging -g 20 > -l 5000). > > So while the paravirt code isn't the most optimal code ever conceived it does work. > > Also, the paravirt patching includes replacing the call with "movb $0, %arg1" > for the native case, which should greatly r...

...bservation, I had not considered that. Thank you. > > > I presume when you did benchmarking this did not even register? Thought > > I wonder if it would if you ran the benchmark for a week or so. > > You presume I benchmarked :-) I managed to boot something virt and run > hackbench in it. I wouldn't know a representative virt setup if I ran > into it. > > The thing is, we want this qspinlock for real hardware because its > faster and I really want to avoid having to carry two spinlock > implementations -- although I suppose that if we really really have to...

...t; convoluted and I've no real way to test that but it should be stright fwd to > make work. > > I ran this using the virtme tool (thanks Andy) on my laptop with a 4x > overcommit on vcpus (16 vcpus as compared to the 4 my laptop actually has) and > it both booted and survived a hackbench run (perf bench sched messaging -g 20 > -l 5000). > > So while the paravirt code isn't the most optimal code ever conceived it does work. > > Also, the paravirt patching includes replacing the call with "movb $0, %arg1" > for the native case, which should greatly r...

...bservation, I had not considered that. Thank you. > > > I presume when you did benchmarking this did not even register? Thought > > I wonder if it would if you ran the benchmark for a week or so. > > You presume I benchmarked :-) I managed to boot something virt and run > hackbench in it. I wouldn't know a representative virt setup if I ran > into it. > > The thing is, we want this qspinlock for real hardware because its > faster and I really want to avoid having to carry two spinlock > implementations -- although I suppose that if we really really have to...

...crease is mainly due to not having access to the 32-bit signed >> relocation that can be used with mcmodel=kernel. A small part is due to reduced >> optimization for PIE code. This bug [1] was opened with gcc to provide a better >> code generation for kernel PIE. >> >> Hackbench (50% and 1600% on thread/process for pipe/sockets): >> - PIE disabled: no significant change (avg +0.1% on latest test). >> - PIE enabled: between -0.50% to +0.86% in average (default and Ubuntu config). >> >> slab_test (average of 10 runs): >> - PIE disabled: no...

...crease is mainly due to not having access to the 32-bit signed >> relocation that can be used with mcmodel=kernel. A small part is due to reduced >> optimization for PIE code. This bug [1] was opened with gcc to provide a better >> code generation for kernel PIE. >> >> Hackbench (50% and 1600% on thread/process for pipe/sockets): >> - PIE disabled: no significant change (avg +0.1% on latest test). >> - PIE enabled: between -0.50% to +0.86% in average (default and Ubuntu config). >> >> slab_test (average of 10 runs): >> - PIE disabled: no...

Hi JF, I've heard that you are interested DSE improvements and maybe we need to be in sync. So far I experimented with following DSE improvements: * Cross-block DSE, it eliminates additional 7% stores comparing to existing DSE. But it's not visible on benchmarks. * Cross-block + Interprocedural analysis to annotate each function argument with: - can read before write - will

...Xen code was a little more convoluted and I've no real way to test that but it should be stright fwd to make work. I ran this using the virtme tool (thanks Andy) on my laptop with a 4x overcommit on vcpus (16 vcpus as compared to the 4 my laptop actually has) and it both booted and survived a hackbench run (perf bench sched messaging -g 20 -l 5000). So while the paravirt code isn't the most optimal code ever conceived it does work. Also, the paravirt patching includes replacing the call with "movb $0, %arg1" for the native case, which should greatly reduce the cost of having CONFI...

...Xen code was a little more convoluted and I've no real way to test that but it should be stright fwd to make work. I ran this using the virtme tool (thanks Andy) on my laptop with a 4x overcommit on vcpus (16 vcpus as compared to the 4 my laptop actually has) and it both booted and survived a hackbench run (perf bench sched messaging -g 20 -l 5000). So while the paravirt code isn't the most optimal code ever conceived it does work. Also, the paravirt patching includes replacing the call with "movb $0, %arg1" for the native case, which should greatly reduce the cost of having CONFI...

...'ve no real way to test that but it should be stright fwd to >> make work. >> >> I ran this using the virtme tool (thanks Andy) on my laptop with a 4x >> overcommit on vcpus (16 vcpus as compared to the 4 my laptop actually has) and >> it both booted and survived a hackbench run (perf bench sched messaging -g 20 >> -l 5000). >> >> So while the paravirt code isn't the most optimal code ever conceived it does work. >> >> Also, the paravirt patching includes replacing the call with "movb $0, %arg1" >> for the native case,...

...'ve no real way to test that but it should be stright fwd to >> make work. >> >> I ran this using the virtme tool (thanks Andy) on my laptop with a 4x >> overcommit on vcpus (16 vcpus as compared to the 4 my laptop actually has) and >> it both booted and survived a hackbench run (perf bench sched messaging -g 20 >> -l 5000). >> >> So while the paravirt code isn't the most optimal code ever conceived it does work. >> >> Also, the paravirt patching includes replacing the call with "movb $0, %arg1" >> for the native case,...

...t; > As for now, I will focus on just having one pending bit. > > I'll throw some ideas at it, One of the ideas follows; it seems sound, but I haven't benchmarked it thoroughly. (Wasted a lot of time by writing/playing with various tools and loads.) Dbench on ext4 ramdisk, hackbench and ebizzy have shown a small improvement in performance, but my main drive was the weird design of Pending Bit. Does your setup yield improvements too? (A minor code swap noted in the patch might help things.) It is meant to be aplied on top of first 7 patches, because the virt stuff would just g...

...; > The size increase is mainly due to not having access to the 32-bit signed > relocation that can be used with mcmodel=kernel. A small part is due to reduced > optimization for PIE code. This bug [1] was opened with gcc to provide a better > code generation for kernel PIE. > > Hackbench (50% and 1600% on thread/process for pipe/sockets): > - PIE disabled: no significant change (avg +0.1% on latest test). > - PIE enabled: between -0.50% to +0.86% in average (default and Ubuntu config). > > slab_test (average of 10 runs): > - PIE disabled: no significant change...

...to not having access to the 32-bit signed >>> relocation that can be used with mcmodel=kernel. A small part is due to reduced >>> optimization for PIE code. This bug [1] was opened with gcc to provide a better >>> code generation for kernel PIE. >>> >>> Hackbench (50% and 1600% on thread/process for pipe/sockets): >>> - PIE disabled: no significant change (avg +0.1% on latest test). >>> - PIE enabled: between -0.50% to +0.86% in average (default and Ubuntu config). >>> >>> slab_test (average of 10 runs): >>&gt...

...d: same - PIE enabled: +0.001% The size increase is mainly due to not having access to the 32-bit signed relocation that can be used with mcmodel=kernel. A small part is due to reduced optimization for PIE code. This bug [1] was opened with gcc to provide a better code generation for kernel PIE. Hackbench (50% and 1600% on thread/process for pipe/sockets): - PIE disabled: no significant change (avg -/+ 0.5% on latest test). - PIE enabled: between -1% to +1% in average (default and Ubuntu config). Kernbench (average of 10 Half and Optimal runs): Elapsed Time: - PIE disabled: no significant chang...