similar to: Paravirt-ops next steps

On Thu, 16 Nov 2006 00:16:26 +0100 Adrian Bunk <bunk@stusta.de> wrote: > Paravirt breaks CONFIG_X86_PAE=y compilation: > > <-- snip --> > > ... > CC init/main.o > In file included from include2/asm/pgtable.h:245, > from > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/mm.h:40, > from >

On Thu, 16 Nov 2006 00:16:26 +0100 Adrian Bunk <bunk@stusta.de> wrote: > Paravirt breaks CONFIG_X86_PAE=y compilation: > > <-- snip --> > > ... > CC init/main.o > In file included from include2/asm/pgtable.h:245, > from > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/mm.h:40, > from >

Fix paravirt_probe() macro so that handing it start_kernel doesn't evoke a warning (start_kernel is asmlinkage). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/dontdiff --minimal linux-2.6.19-rc4-mm2/include/asm-i386/paravirt.h working-2.6.19-rc4-mm2-warnings/include/asm-i386/paravirt.h ---

Fix paravirt_probe() macro so that handing it start_kernel doesn't evoke a warning (start_kernel is asmlinkage). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/dontdiff --minimal linux-2.6.19-rc4-mm2/include/asm-i386/paravirt.h working-2.6.19-rc4-mm2-warnings/include/asm-i386/paravirt.h ---

OK, at least two patches got dropped on the way from the mm tree to Andi's tree: the desc.h cleanup, and the processor.h rearrangement. Merging into Andi's tree without these patches must have been a nightmare 8( Andi then tried to fix it with x86_64-mm-paravirt-compile.patch but then it didn't boot so he disabled it in x86_64-mm-paravirt-broken.patch This patch undoes those two

OK, at least two patches got dropped on the way from the mm tree to Andi's tree: the desc.h cleanup, and the processor.h rearrangement. Merging into Andi's tree without these patches must have been a nightmare 8( Andi then tried to fix it with x86_64-mm-paravirt-compile.patch but then it didn't boot so he disabled it in x86_64-mm-paravirt-broken.patch This patch undoes those two

Hello, Here is my first speedup patch. Like 10-11%. No IDCT yet. Please feel free to comment my code or even better think about improvements. :) I belive my routines are not so bad, maybe one day they will be even more faster. What needs to be optimized is the loop filter fuction. I have no ideas now how to do it. It does not leave much space for parallel stuff, copying memory from lot of

So, as 2.6.21-rc1 is approaching, what is the upstream merge status for the paravirt-ops backends? I believe VMI is in Andi's tree, plus or minus some bugfixes that are still being whittled in, but Andi, do you think the VMI code is in good shape for merging? It would be nice for everyone to clarify their upstream plans - is the goal still to get Xen and lguest merged for the next kernel

So, as 2.6.21-rc1 is approaching, what is the upstream merge status for the paravirt-ops backends? I believe VMI is in Andi's tree, plus or minus some bugfixes that are still being whittled in, but Andi, do you think the VMI code is in good shape for merging? It would be nice for everyone to clarify their upstream plans - is the goal still to get Xen and lguest merged for the next kernel

Hi, It seems LLVM-MC is broken with Avx512? $ echo "vinserti32x4 \$1, %xmm21, %zmm5, %zmm17"|./Release+Asserts/bin/llvm-mc -assemble -arch=x86-64 -show-encoding -x86-asm-syntax=att .text vinserti32x4 $1, %xmm21, %zmm5, %zmm17 # encoding: [0x62,0xa3,0x55,0x48,0x38,0xcd,0x01] $ echo "0x62,0xa3,0x55,0x48,0x38,0xcd,0x01" |./Release+Asserts/bin/llvm-mc -disassemble

Well, you’ll probably need to specify which CPU for the instructions to be recognized as valid encodings. -mcpu=knl doesn’t seem sufficient, though, so there’s probably something more going on. Elena, do you know what’s happening here? It’s important that the disassembler work with the new instructions as well as the assembler. I looked but didn’t see any disassembler tests for avx512. -Jim On

Full_Name: Renaud Lancelot Version: Version 2.3.0 (2006-04-24) OS: MS Windows XP Pro SP2 Submission from: (NULL) (82.239.219.108) I think there is a bug in predict.lme, when a polynomial generated by poly() is used as an explanatory variable, and a new data.frame is used for predictions. I guess this is related to * not * using, for predictions, the coefs used in constructing the orthogonal

Hi all, I'm struggling a bit to get pgfSweave to lazyload objects when compiling a .Rnw file for a second time. Caching works fine except that for every run all objects get cached again and again. I've used cacheSweave which works fine; all cached objects from code-chunks with option cache = TRUE are lazy loaded. I've tried it on two machines ... I'm pretty sure I'm

On Monday 18 June 2007 19:02, Christopher Lamb wrote: > Take a look at getPhysicalRegisterRegClass( > const MRegisterInfo *MRI, > MVT::ValueType VT, > unsigned reg) > > in ScheduleDAG.cpp. Yuck. I was afraid of that. What is the ValueType needed for? Isn't the register id itself an indication of the ValueType it represents? Where I'm at I

Dear all, We have developed our own Affymetrix chip (Custom Express Array, PM-only with two species). I want to analyse the data with the limma package, but for that I need to built my own CDF package, probe package and built the filters to analyse one specie or another. I'm using the makeProbePackage available in the AnnotationDbi (for a R-2.13.0) but I got the following error message:

quite some speed improvement indeed. attached the updated patch to apply to svn/trunk. j -------------- next part -------------- A non-text attachment was scrubbed... Name: theora-mmx.patch.gz Type: application/x-gzip Size: 8648 bytes Desc: not available Url : http://lists.xiph.org/pipermail/theora-dev/attachments/20040824/5a5f2731/theora-mmx.patch-0001.bin

Hello, I would like to announce the semi-optimized oc_state_loop_filter_frag_rows It gains like 7% speedup. Unfortunately it has some issues: 1) wont compile on 64bit (I will fix it later hopefully) 2) is not yet fully optimized (instruction stalls) Here are the results. CPU: Athlon, speed 1466.91 MHz (estimated) Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask

I have optimized FLAC__fixed_compute_best_predictor_asm_ia32_mmx_cmov function and fixed bug when data_len == 0. Now the function is about 50% faster and flac -5 is about 5% faster on my box. I have tested it thoroughly, I think it can go to flac 1.0.4. -- Miroslav Lichvar -------------- next part -------------- --- src/libFLAC/ia32/fixed_asm.nasm.orig 2002-01-26 19:05:12.000000000 +0100 +++

On 20.10.2010 05:00, Jakob Stoklund Olesen wrote: > On Oct 19, 2010, at 6:37 PM, Roland Scheidegger wrote: > >> Thanks for giving it a look! >> >> On 19.10.2010 23:21, Jakob Stoklund Olesen wrote: >>> On Oct 19, 2010, at 11:40 AM, Roland Scheidegger wrote: >>> >>>> So I saw that the code is doing lots of register >>>>

Okay, now, before 3.10 is finalized... what bug reports am I still forgetting? -hpa