Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1374751 > unrolled thread
| Started by | James Simmons <jsimmons@infradead.org> |
|---|---|
| First post | 2016-04-10 15:20 +0200 |
| Last post | 2016-04-10 23:20 +0200 |
| Articles | 6 — 3 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
[PATCH 13/17] staging: lustre: lloop: Fix build failure on ppc64 James Simmons <jsimmons@infradead.org> - 2016-04-10 15:20 +0200
Re: [PATCH 13/17] staging: lustre: lloop: Fix build failure on ppc64 Jeff Mahoney <jeffm@suse.com> - 2016-04-10 15:30 +0200
Re: [PATCH 13/17] staging: lustre: lloop: Fix build failure on ppc64 James Simmons <jsimmons@infradead.org> - 2016-04-10 16:10 +0200
Re: [PATCH 13/17] staging: lustre: lloop: Fix build failure on ppc64 Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-04-10 17:40 +0200
Re: [PATCH 13/17] staging: lustre: lloop: Fix build failure on ppc64 James Simmons <jsimmons@infradead.org> - 2016-04-10 18:00 +0200
Re: [PATCH 13/17] staging: lustre: lloop: Fix build failure on ppc64 Jeff Mahoney <jeffm@suse.com> - 2016-04-10 23:20 +0200
| From | James Simmons <jsimmons@infradead.org> |
|---|---|
| Date | 2016-04-10 15:20 +0200 |
| Subject | [PATCH 13/17] staging: lustre: lloop: Fix build failure on ppc64 |
| Message-ID | <rmnrs-5Be-11@gated-at.bofh.it> |
From: Jeff Mahoney <jeffm@suse.com> On ppc64 with 64k pages, we get a build failure in lloop: drivers/staging/lustre/lustre/llite/lloop.c:527:2: note: in expansion of macro 'CLASSERT' CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8))); There's no need to change the queue's logical block size. Even if it could accept a 64k value, that would result in any file system on top of it needing to also use 64k blocks. It'd be safe to set it to 4k, but there's no actual need for it. It's not used to split requests except for WRITE_SAME, which lloop doesn't implement anyway. Signed-off-by: Jeff Mahoney <jeffm@suse.com> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4000 Reviewed-on: http://review.whamcloud.com/7745 Reviewed-by: Jinshan Xiong <jinshan.xiong@intel.com> Reviewed-by: Minh Diep <minh.diep@intel.com> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> --- drivers/staging/lustre/lustre/llite/lloop.c | 3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/staging/lustre/lustre/llite/lloop.c b/drivers/staging/lustre/lustre/llite/lloop.c index b725fc1..f396753 100644 --- a/drivers/staging/lustre/lustre/llite/lloop.c +++ b/drivers/staging/lustre/lustre/llite/lloop.c @@ -525,9 +525,6 @@ static int loop_set_fd(struct lloop_device *lo, struct file *unused, lo->lo_queue->queuedata = lo; /* queue parameters */ - CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8))); - blk_queue_logical_block_size(lo->lo_queue, - (unsigned short)PAGE_CACHE_SIZE); blk_queue_max_hw_sectors(lo->lo_queue, LLOOP_MAX_SEGMENTS << (PAGE_CACHE_SHIFT - 9)); blk_queue_max_segments(lo->lo_queue, LLOOP_MAX_SEGMENTS); -- 1.7.1
[toc] | [next] | [standalone]
| From | Jeff Mahoney <jeffm@suse.com> |
|---|---|
| Date | 2016-04-10 15:30 +0200 |
| Message-ID | <rmnB9-5GJ-9@gated-at.bofh.it> |
| In reply to | #1374751 |
This patch was shown not to work. I just haven't removed it from opensuse yet. -Jeff -- Jeff Mahoney (apologies for the top post -- from my mobile) > On Apr 10, 2016, at 9:13 AM, James Simmons <jsimmons@infradead.org> wrote: > > From: Jeff Mahoney <jeffm@suse.com> > > On ppc64 with 64k pages, we get a build failure in lloop: > > drivers/staging/lustre/lustre/llite/lloop.c:527:2: > note: in expansion of macro 'CLASSERT' > CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8))); > > There's no need to change the queue's logical block size. Even if it could > accept a 64k value, that would result in any file system on top of it > needing to also use 64k blocks. It'd be safe to set it to 4k, but there's > no actual need for it. It's not used to split requests except for WRITE_SAME, > which lloop doesn't implement anyway. > > Signed-off-by: Jeff Mahoney <jeffm@suse.com> > Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4000 > Reviewed-on: http://review.whamcloud.com/7745 > Reviewed-by: Jinshan Xiong <jinshan.xiong@intel.com> > Reviewed-by: Minh Diep <minh.diep@intel.com> > Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> > Signed-off-by: James Simmons <jsimmons@infradead.org> > --- > drivers/staging/lustre/lustre/llite/lloop.c | 3 --- > 1 files changed, 0 insertions(+), 3 deletions(-) > > diff --git a/drivers/staging/lustre/lustre/llite/lloop.c b/drivers/staging/lustre/lustre/llite/lloop.c > index b725fc1..f396753 100644 > --- a/drivers/staging/lustre/lustre/llite/lloop.c > +++ b/drivers/staging/lustre/lustre/llite/lloop.c > @@ -525,9 +525,6 @@ static int loop_set_fd(struct lloop_device *lo, struct file *unused, > lo->lo_queue->queuedata = lo; > > /* queue parameters */ > - CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8))); > - blk_queue_logical_block_size(lo->lo_queue, > - (unsigned short)PAGE_CACHE_SIZE); > blk_queue_max_hw_sectors(lo->lo_queue, > LLOOP_MAX_SEGMENTS << (PAGE_CACHE_SHIFT - 9)); > blk_queue_max_segments(lo->lo_queue, LLOOP_MAX_SEGMENTS); > -- > 1.7.1 > >
[toc] | [prev] | [next] | [standalone]
| From | James Simmons <jsimmons@infradead.org> |
|---|---|
| Date | 2016-04-10 16:10 +0200 |
| Subject | Re: [PATCH 13/17] staging: lustre: lloop: Fix build failure on ppc64 |
| Message-ID | <rmodQ-6er-11@gated-at.bofh.it> |
| In reply to | #1374773 |
> This patch was shown not to work. I just haven't removed it from opensuse yet. Its been running in our production tree as well for some time. Guess that change is a noop. In any case we have been discussing redoing the lloop driver anyways. Just need to find the cycles. > -- > Jeff Mahoney > (apologies for the top post -- from my mobile) > > > On Apr 10, 2016, at 9:13 AM, James Simmons <jsimmons@infradead.org> wrote: > > > > From: Jeff Mahoney <jeffm@suse.com> > > > > On ppc64 with 64k pages, we get a build failure in lloop: > > > > drivers/staging/lustre/lustre/llite/lloop.c:527:2: > > note: in expansion of macro 'CLASSERT' > > CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8))); > > > > There's no need to change the queue's logical block size. Even if it could > > accept a 64k value, that would result in any file system on top of it > > needing to also use 64k blocks. It'd be safe to set it to 4k, but there's > > no actual need for it. It's not used to split requests except for WRITE_SAME, > > which lloop doesn't implement anyway. > > > > Signed-off-by: Jeff Mahoney <jeffm@suse.com> > > Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4000 > > Reviewed-on: http://review.whamcloud.com/7745 > > Reviewed-by: Jinshan Xiong <jinshan.xiong@intel.com> > > Reviewed-by: Minh Diep <minh.diep@intel.com> > > Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> > > Signed-off-by: James Simmons <jsimmons@infradead.org> > > --- > > drivers/staging/lustre/lustre/llite/lloop.c | 3 --- > > 1 files changed, 0 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/staging/lustre/lustre/llite/lloop.c b/drivers/staging/lustre/lustre/llite/lloop.c > > index b725fc1..f396753 100644 > > --- a/drivers/staging/lustre/lustre/llite/lloop.c > > +++ b/drivers/staging/lustre/lustre/llite/lloop.c > > @@ -525,9 +525,6 @@ static int loop_set_fd(struct lloop_device *lo, struct file *unused, > > lo->lo_queue->queuedata = lo; > > > > /* queue parameters */ > > - CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8))); > > - blk_queue_logical_block_size(lo->lo_queue, > > - (unsigned short)PAGE_CACHE_SIZE); > > blk_queue_max_hw_sectors(lo->lo_queue, > > LLOOP_MAX_SEGMENTS << (PAGE_CACHE_SHIFT - 9)); > > blk_queue_max_segments(lo->lo_queue, LLOOP_MAX_SEGMENTS); > > -- > > 1.7.1 > > > > > >
[toc] | [prev] | [next] | [standalone]
| From | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2016-04-10 17:40 +0200 |
| Message-ID | <rmpCW-7aV-5@gated-at.bofh.it> |
| In reply to | #1374785 |
On Sun, Apr 10, 2016 at 03:04:51PM +0100, James Simmons wrote: > > > This patch was shown not to work. I just haven't removed it from opensuse yet. > > Its been running in our production tree as well for some time. Guess that > change is a noop. In any case we have been discussing redoing the lloop > driver anyways. Just need to find the cycles. Why do you need this driver? I know Christoph has pointed out many times that it should just be dropped as it's not needed. And should I drop this patch from the series? thanks, greg k-h
[toc] | [prev] | [next] | [standalone]
| From | James Simmons <jsimmons@infradead.org> |
|---|---|
| Date | 2016-04-10 18:00 +0200 |
| Subject | Re: [PATCH 13/17] staging: lustre: lloop: Fix build failure on ppc64 |
| Message-ID | <rmpWi-7iY-13@gated-at.bofh.it> |
| In reply to | #1374808 |
> > > This patch was shown not to work. I just haven't removed it from opensuse yet. > > > > Its been running in our production tree as well for some time. Guess that > > change is a noop. In any case we have been discussing redoing the lloop > > driver anyways. Just need to find the cycles. > > Why do you need this driver? I know Christoph has pointed out many > times that it should just be dropped as it's not needed. Please don't drop this driver just yet. The reason we kept it was for the DIO support that the loop back device lacked earlier. We need to do some testing to make sure the loop can completely replace this driver. > And should I drop this patch from the series? Yes since it is a noop. No other patches are dependent on it.
[toc] | [prev] | [next] | [standalone]
| From | Jeff Mahoney <jeffm@suse.com> |
|---|---|
| Date | 2016-04-10 23:20 +0200 |
| Message-ID | <rmuVY-2UD-11@gated-at.bofh.it> |
| In reply to | #1374785 |
[Multipart message — attachments visible in raw view] — view raw
On 4/10/16 10:04 AM, James Simmons wrote: > >> This patch was shown not to work. I just haven't removed it from opensuse yet. > > Its been running in our production tree as well for some time. Guess that > change is a noop. In any case we have been discussing redoing the lloop > driver anyways. Just need to find the cycles. I guess my memory was flakey and I was recalling the first comments in LU-4000. The updated version should be ok. -Jeff >> -- >> Jeff Mahoney >> (apologies for the top post -- from my mobile) >> >>> On Apr 10, 2016, at 9:13 AM, James Simmons <jsimmons@infradead.org> wrote: >>> >>> From: Jeff Mahoney <jeffm@suse.com> >>> >>> On ppc64 with 64k pages, we get a build failure in lloop: >>> >>> drivers/staging/lustre/lustre/llite/lloop.c:527:2: >>> note: in expansion of macro 'CLASSERT' >>> CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8))); >>> >>> There's no need to change the queue's logical block size. Even if it could >>> accept a 64k value, that would result in any file system on top of it >>> needing to also use 64k blocks. It'd be safe to set it to 4k, but there's >>> no actual need for it. It's not used to split requests except for WRITE_SAME, >>> which lloop doesn't implement anyway. >>> >>> Signed-off-by: Jeff Mahoney <jeffm@suse.com> >>> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4000 >>> Reviewed-on: http://review.whamcloud.com/7745 >>> Reviewed-by: Jinshan Xiong <jinshan.xiong@intel.com> >>> Reviewed-by: Minh Diep <minh.diep@intel.com> >>> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> >>> Signed-off-by: James Simmons <jsimmons@infradead.org> >>> --- >>> drivers/staging/lustre/lustre/llite/lloop.c | 3 --- >>> 1 files changed, 0 insertions(+), 3 deletions(-) >>> >>> diff --git a/drivers/staging/lustre/lustre/llite/lloop.c b/drivers/staging/lustre/lustre/llite/lloop.c >>> index b725fc1..f396753 100644 >>> --- a/drivers/staging/lustre/lustre/llite/lloop.c >>> +++ b/drivers/staging/lustre/lustre/llite/lloop.c >>> @@ -525,9 +525,6 @@ static int loop_set_fd(struct lloop_device *lo, struct file *unused, >>> lo->lo_queue->queuedata = lo; >>> >>> /* queue parameters */ >>> - CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8))); >>> - blk_queue_logical_block_size(lo->lo_queue, >>> - (unsigned short)PAGE_CACHE_SIZE); >>> blk_queue_max_hw_sectors(lo->lo_queue, >>> LLOOP_MAX_SEGMENTS << (PAGE_CACHE_SHIFT - 9)); >>> blk_queue_max_segments(lo->lo_queue, LLOOP_MAX_SEGMENTS); >>> -- >>> 1.7.1 >>> >>> >> >> > -- Jeff Mahoney SUSE Labs
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web