search for: v20

...,r31,lo16(L1300) L1199: mtctr r31 ; set up invariant vectors vspltish v16,0 ; v16: zero vector li r10,-12 lvsr v17,r10,r8 ; v17: result shift vector lvsl v18,r10,r3 ; v18: residual shift back vector li r10,-4 stw r7,-4(r9) lvewx v19,r10,r9 ; v19: lp_quantization vector L1200: vmulosh v20,v0,v8 ; v20: sum vector bcctr 20,0 L1300: vmulosh v21,v7,v15 vsldoi v15,v15,v14,4 ; increment history vaddsws v20,v20,v21 L1301: vmulosh v21,v6,v14 vsldoi v14,v14,v13,4 vaddsws v20,v20,v21 L1302: vmulosh v21,v5,v13 vsldoi v13,v13,v12,4 vaddsws v20,v20,v21 L1303: vmulosh v21,v4,v12 v...

Sadly the latest optimization broke completely everything. The asm code isn't gas compliant. the libFLAC linker script has a typo, disabling the asm optimization and/or altivec won't let a correct build anyway. Instant fixes for the asm stuff: sed -i -e"s:;:\#:" on the lpc_asm.s to load address instead of addis+ori you could use lis and la and PLEASE use the @l(register)

On Tue, Dec 19, 2017 at 11:05:11PM +0900, Tetsuo Handa wrote: > Wei Wang wrote: > > ChangeLog: > > v19->v20: > > 1) patch 1: xbitmap > > - add __rcu to "void **slot"; > > - remove the exceptional path. > > 2) patch 3: xbitmap > > - DeveloperNotes: add an item to comment that the current bit range > > related APIs operating on extremely large ranges (e.g...

...39;s actually caused by the previous "!node" path, which incorrectly changed "index = (index | RADIX_TREE_MAP_MASK) + 1". With the change below, it will run pretty well with the test cases. if (!node && !bitmap) return size; Would you mind to have a try with the v20 RESEND patch that was just shared? It makes the above change and added the test case you suggested? One more question is about the return value, why would it be ambiguous? I think it is the same as find_next_bit() which returns the found bit or size if not found. Best, Wei

On Tue, Dec 19, 2017 at 11:05:11PM +0900, Tetsuo Handa wrote: > Wei Wang wrote: > > ChangeLog: > > v19->v20: > > 1) patch 1: xbitmap > > - add __rcu to "void **slot"; > > - remove the exceptional path. > > 2) patch 3: xbitmap > > - DeveloperNotes: add an item to comment that the current bit range > > related APIs operating on extremely large ranges (e.g...

...,3,4,5,6) V8 <- c(0,1) V9 <- c(0,1) V10 <- c(0,1) V11 <- c(0,1) V12 <- c(0,1) V13 <- c(0,1) V14 <- c(0,1) V15 <- c(0,1,2,3,4,5,6,7,8,9) V16 <- c(0,1,2,3,4,5,6) V17 <- c(0,1,2,3,4,5,6,7,8) V18 <- c(0,1,2,3,4,5) V19 <- c(0,1) V20 <- c(0,1,2,3,4,5,6,7) When run expand.grid I found a problem: > all.V <- expand.grid(V1,V2,V3,V4,V5,V6,V7,V8,V9,V10,V11,V12,V13,V14,V15,V16,V17,V18,V19,V20) Error in rep.int(rep.int(x, rep.int(rep.fac, nx)), orep) : invalid number of copies in rep() In addition: Warning mess...

On 12/19/2017 10:05 PM, Tetsuo Handa wrote: > Wei Wang wrote: >> ChangeLog: >> v19->v20: >> 1) patch 1: xbitmap >> - add __rcu to "void **slot"; >> - remove the exceptional path. >> 2) patch 3: xbitmap >> - DeveloperNotes: add an item to comment that the current bit range >> related APIs operating on extremely large ranges (e.g. >...

On 12/19/2017 10:05 PM, Tetsuo Handa wrote: > Wei Wang wrote: >> ChangeLog: >> v19->v20: >> 1) patch 1: xbitmap >> - add __rcu to "void **slot"; >> - remove the exceptional path. >> 2) patch 3: xbitmap >> - DeveloperNotes: add an item to comment that the current bit range >> related APIs operating on extremely large ranges (e.g. >...

Hi, i have to reshape a dataset. my data have the following format: ID; x1; x2; x3; x4; v1; ... v20 1; 0.1; 0.3; 0.4; 0.2; 2; ... 3 2; 0.3; 0.7; 0.1; 0.2; 1; ... 4 ... 999; 0.9; 0.6; 0.3; 0.1; 4; ... 2 1000; 0.2; 0.6; 0.7; 0.8; 1; ... 5 ID is the number of persons (here 1000 persons) x are descriptive variables and v1-v20 are values of satisfaction on holidays for 20 days and now i shou...

On Tue, Dec 19, 2017 at 11:05:11PM +0900, Tetsuo Handa wrote: > Removing exceptional path made this patch easier to read. > But what I meant is > > Can you eliminate exception path and fold all xbitmap patches into one, and > post only one xbitmap patch without virtio-balloon changes? > > . > > I still think we don't need xb_preload()/xb_preload_end(). > I

On Wed, Dec 20, 2017 at 06:34:36PM +0800, Wei Wang wrote: > On 12/19/2017 10:05 PM, Tetsuo Handa wrote: > > I think xb_find_set() has a bug in !node path. > > I think we can probably remove the "!node" path for now. It would be good to > get the fundamental part in first, and leave optimization to come as > separate patches with corresponding test cases in the

On 12/21/2017 10:37 PM, Tetsuo Handa wrote: > Matthew Wilcox wrote: >>> +/** >>> + * xb_find_set - find the next set bit in a range of bits >>> + * @xb: the xbitmap to search from >>> + * @offset: the offset in the range to start searching >>> + * @size: the size of the range >>> + * >>> + * Returns: the found bit or, @size if no

On 12/23/2017 10:33 PM, Tetsuo Handa wrote: >>>> + bitmap = rcu_dereference_raw(*slot); >>>> + if (!bitmap) { >>>> + bitmap = this_cpu_xchg(ida_bitmap, NULL); >>>> + if (!bitmap) >>>> + return -ENOMEM; >>> I can't understand this. I can understand if it were >>> >>> BUG_ON(!bitmap); >>>

On Fri, Dec 22, 2017 at 04:49:11PM +0800, Wei Wang wrote: > Thanks for the improvement. I also found a small bug in xb_zero. With the > following changes, it has passed the current test cases and tested with the > virtio-balloon usage without any issue. Thanks; I applied the change. Can you supply a test-case for testing xb_zero please? > > @@ -25,8 +26,11 @@ idr-test: idr-test.o

On 01/03/2018 10:29 AM, Tetsuo Handa wrote: > Matthew Wilcox wrote: >> The radix tree convention is objectively awful, which is why I'm working >> to change it. Specifying the GFP flags at radix tree initialisation time >> rather than allocation time leads to all kinds of confusion. The preload >> API is a pretty awful workaround, and it will go away once the

On Tue, Dec 19, 2017 at 11:05:11PM +0900, Tetsuo Handa wrote: > Removing exceptional path made this patch easier to read. > But what I meant is > > Can you eliminate exception path and fold all xbitmap patches into one, and > post only one xbitmap patch without virtio-balloon changes? > > . > > I still think we don't need xb_preload()/xb_preload_end(). > I

On Sat, Dec 23, 2017 at 11:59:54AM +0900, Tetsuo Handa wrote: > Matthew Wilcox wrote: > > + bit %= IDA_BITMAP_BITS; > > + radix_tree_iter_init(&iter, index); > > + slot = idr_get_free_cmn(root, &iter, GFP_NOWAIT | __GFP_NOWARN, index); > > + if (IS_ERR(slot)) { > > + if (slot == ERR_PTR(-ENOSPC)) > > + return 0; /* Already set */ > > Why

...em, related to the possibility of changing the shape of a data frame using a "pivoting-like" function. I have a dataframe df of observations as follows: ID VALIDITY YEAR PROPERTY PROPERTY VALUE A1 2007 P1 V1 A1 2007 P2 V2 A1 2007 P3 V3 A1 2008 P1 V10 A1 2008 P2 V20 A2 2007 P5 V50 A2 2008 P6 V20 A3 2007 P1 V1 A3 2007 P3 V30 A3 2008 P1 V10 A3 2008 P2 V4 A3 2008 P6 V25 (you can imagine that this data is collected every year from a sample of people with several "measures" - weight, number of children, income... It can...

Provide a splice_read stub for ocfs2. This emits trace lines and does an atime lock/update before calling filemap_splice_read(). It doesn't do this for around direct_splice_read() as that will call ->read_iter(). A couple of new tracepoints are added for this purpose. Signed-off-by: David Howells <dhowells at redhat.com> cc: Christoph Hellwig <hch at lst.de> cc: Al Viro

On Sat, Dec 23, 2017 at 11:33:45PM +0900, Tetsuo Handa wrote: > Matthew Wilcox wrote: > > On Sat, Dec 23, 2017 at 11:59:54AM +0900, Tetsuo Handa wrote: > > > Matthew Wilcox wrote: > > > > + bit %= IDA_BITMAP_BITS; > > > > + radix_tree_iter_init(&iter, index); > > > > + slot = idr_get_free_cmn(root, &iter, GFP_NOWAIT | __GFP_NOWARN,