search for: v19

...nelia.huck at de.ibm.com; > mgorman at techsingularity.net; aarcange at redhat.com; > amit.shah at redhat.com; pbonzini at redhat.com; > liliang.opensource at gmail.com; yang.zhang.wz at gmail.com; > quan.xu at aliyun.com; nilal at redhat.com; riel at redhat.com > Subject: Re: [PATCH v19 3/7] xbitmap: add more operations > > Wei Wang wrote: > > > But passing GFP_NOWAIT means that we can handle allocation failure. > > > There is no need to use preload approach when we can handle allocation > failure. > > > > I think the reason we need xb_prelo...

...V7 <- c(0,1,2,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 ad...

...e** %v1 ; ... %gep9 = getelementptr inbounds %Slice* %v6, i32 0, i32 0 %v10 = load double** %gep9 ; v13 = <index calculation> ; ... %addr = getelementptr double* %v10, i64 %v13 %getitem = load double* %addr ;... %gep18 = getelementptr inbounds %Slice* %v14, i32 0, i32 0 %v19 = load double** %gep18 ; v22 = <index calculation> ; ... %addr23 = getelementptr double* %v19, i64 %v22 %getitem24 = load double* %addr23 ---- /IR ---- Right now I'm forwarding alias() calls to base class and just observing the current alias analysis result. Here's a portio...

On Fri, Dec 15, 2017 at 01:29:45AM +0900, Tetsuo Handa wrote: > > > Also, one more thing you need to check. Have you checked how long does > > > xb_find_next_set_bit(xb, 0, ULONG_MAX) on an empty xbitmap takes? > > > If it causes soft lockup warning, should we add cond_resched() ? > > > If yes, you have to document that this API might sleep. If no, you > >

On Sat, Dec 16, 2017 at 01:21:52AM +0900, Tetsuo Handa wrote: > My understanding is that virtio-balloon wants to handle sparsely spreaded > unsigned long values (which is PATCH 4/7) and wants to find all chunks of > consecutive "1" bits efficiently. Therefore, I guess that holding the values > in ascending order at store time is faster than sorting the values at read >

On Sat, Dec 16, 2017 at 01:31:24PM +0900, Tetsuo Handa wrote: > Michael S. Tsirkin wrote: > > On Sat, Dec 16, 2017 at 01:21:52AM +0900, Tetsuo Handa wrote: > > > My understanding is that virtio-balloon wants to handle sparsely spreaded > > > unsigned long values (which is PATCH 4/7) and wants to find all chunks of > > > consecutive "1" bits

On Fri, Dec 15, 2017 at 07:05:07PM +0800, kbuild test robot wrote: > 21 struct radix_tree_node *node; > 22 void **slot; ^^^ missing __rcu annotation here. Wei, could you fold that change into your next round? Thanks!

On 12/15/2017 12:29 AM, Tetsuo Handa wrote: > Wei Wang wrote: >> I used the example of xb_clear_bit_range(), and xb_find_next_bit() is >> the same fundamentally. Please let me know if anywhere still looks fuzzy. > I don't think it is the same for xb_find_next_bit() with set == 0. > > + if (radix_tree_exception(bmap)) { > + unsigned long tmp = (unsigned long)bmap;

On 12/16/2017 07:28 PM, Tetsuo Handa wrote: > Wei Wang wrote: >> On 12/16/2017 02:42 AM, Matthew Wilcox wrote: >>> On Tue, Dec 12, 2017 at 07:55:55PM +0800, Wei Wang wrote: >>>> +int xb_preload_and_set_bit(struct xb *xb, unsigned long bit, gfp_t gfp); >>> I'm struggling to understand when one would use this. The xb_ API >>> requires you to

On Saturday, December 16, 2017 3:22 AM, Matthew Wilcox wrote: > On Fri, Dec 15, 2017 at 10:49:15AM -0800, Matthew Wilcox wrote: > > Here's the API I'm looking at right now. The user need take no lock; > > the locking (spinlock) is handled internally to the implementation. Another place I saw your comment " The xb_ API requires you to handle your own locking"

On 12/18/2017 06:18 AM, Matthew Wilcox wrote: > On Sun, Dec 17, 2017 at 01:47:21PM +0000, Wang, Wei W wrote: >> On Saturday, December 16, 2017 3:22 AM, Matthew Wilcox wrote: >>> On Fri, Dec 15, 2017 at 10:49:15AM -0800, Matthew Wilcox wrote: >>> - xbit_clear() can't return an error. Neither can xbit_zero(). >> I found the current xbit_clear implementation

On 12/17/2017 11:16 PM, Tetsuo Handa wrote: > Wang, Wei W wrote: >>> Wei Wang wrote: >>>>> But passing GFP_NOWAIT means that we can handle allocation failure. >>>>> There is no need to use preload approach when we can handle allocation failure. >>>> I think the reason we need xb_preload is because radix tree insertion >>>> needs the

On Sat, Dec 16, 2017 at 01:21:52AM +0900, Tetsuo Handa wrote: > My understanding is that virtio-balloon wants to handle sparsely spreaded > unsigned long values (which is PATCH 4/7) and wants to find all chunks of > consecutive "1" bits efficiently. Therefore, I guess that holding the values > in ascending order at store time is faster than sorting the values at read >

Hi Matthew, I love your patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.15-rc3] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Wei-Wang/Virtio-balloon-Enhancement/20171215-100525 reproduce: # apt-get install sparse

Hi Matthew, I love your patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.15-rc3] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Wei-Wang/Virtio-balloon-Enhancement/20171215-100525 reproduce: # apt-get install sparse

On 12/12/2017 09:20 PM, Tetsuo Handa wrote: > Wei Wang wrote: >> +void xb_clear_bit_range(struct xb *xb, unsigned long start, unsigned long end) >> +{ >> + struct radix_tree_root *root = &xb->xbrt; >> + struct radix_tree_node *node; >> + void **slot; >> + struct ida_bitmap *bitmap; >> + unsigned int nbits; >> + >> + for (; start <

On 12/13/2017 10:16 PM, Tetsuo Handa wrote: > Wei Wang wrote: >> On 12/12/2017 09:20 PM, Tetsuo Handa wrote: >>> Wei Wang wrote: >>>> +void xb_clear_bit_range(struct xb *xb, unsigned long start, unsigned long end) >>>> +{ >>>> + struct radix_tree_root *root = &xb->xbrt; >>>> + struct radix_tree_node *node; >>>> +

On Tue, Dec 12, 2017 at 07:55:55PM +0800, Wei Wang wrote: > +int xb_preload_and_set_bit(struct xb *xb, unsigned long bit, gfp_t gfp); I'm struggling to understand when one would use this. The xb_ API requires you to handle your own locking. But specifying GFP flags here implies you can sleep. So ... um ... there's no locking? > +void xb_clear_bit_range(struct xb *xb, unsigned

On Tue, Dec 12, 2017 at 07:55:55PM +0800, Wei Wang wrote: > +int xb_preload_and_set_bit(struct xb *xb, unsigned long bit, gfp_t gfp); I'm struggling to understand when one would use this. The xb_ API requires you to handle your own locking. But specifying GFP flags here implies you can sleep. So ... um ... there's no locking? > +void xb_clear_bit_range(struct xb *xb, unsigned

This patch made some changes to the original xbitmap implementation from the linux-dax tree: - remove xb_fill() and xb_zero() from xbitmap.h since they are not implemented; - xb_test_bit: changed "ebit > BITS_PER_LONG" to "ebit >= BITS_PER_LONG", because bit 64 beyonds the "unsigned long" exceptional entry (0 to 63); - xb_set_bit: delete the new inserted