Re: [PATCH 0/3] Use sbitmap instead of percpu_ida

2018-06-18 Thread Martin K. Petersen
Matthew, >> Since most of the changes are in scsi or target, should I take this >> series through my tree? > > I'd welcome that. Nick seems to be inactive as target maintainer; > his tree on kernel.org hasn't seen any updates in five months. Applied to 4.19/scsi-queue, thanks! -- Martin K. P

Re: [PATCH 0/3] Use sbitmap instead of percpu_ida

2018-06-15 Thread Christoph Hellwig
Btw, if you are on a spree to remove almost unused data structures from target code, the lib/btree.c code is only used by the qla2xxx target code, and doesn't really look like the best fit for it either. ___ Virtualization mailing list Virtualization@list

Re: [PATCH 0/3] Use sbitmap instead of percpu_ida

2018-06-14 Thread Matthew Wilcox
On Thu, Jun 14, 2018 at 10:06:58PM -0400, Martin K. Petersen wrote: > > Matthew, > > > Removing the percpu_ida code nets over 400 lines of removal. It's not > > as spectacular as deleting an entire architecture, but it's still a > > worthy reduction in lines of code. > > Since most of the chang

Re: [PATCH 0/3] Use sbitmap instead of percpu_ida

2018-06-14 Thread Martin K. Petersen
Matthew, > Removing the percpu_ida code nets over 400 lines of removal. It's not > as spectacular as deleting an entire architecture, but it's still a > worthy reduction in lines of code. Since most of the changes are in scsi or target, should I take this series through my tree? -- Martin K.

Re: [PATCH 0/3] Use sbitmap instead of percpu_ida

2018-06-12 Thread Jens Axboe
On 6/12/18 1:05 PM, Matthew Wilcox wrote: > Removing the percpu_ida code nets over 400 lines of removal. It's not > as spectacular as deleting an entire architecture, but it's still a > worthy reduction in lines of code. > > Untested due to lack of hardware and not understanding how to set up a >

Re: [PATCH 0/3] Use sbitmap instead of percpu_ida

2018-06-12 Thread Bart Van Assche
On Tue, 2018-06-12 at 12:05 -0700, Matthew Wilcox wrote: > Removing the percpu_ida code nets over 400 lines of removal. It's not > as spectacular as deleting an entire architecture, but it's still a > worthy reduction in lines of code. > > Untested due to lack of hardware and not understanding ho