From: Jeff Mahoney <jeffm@suse.com>
To: James Simmons <jsimmons@infradead.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
devel@driverdev.osuosl.org,
Andreas Dilger <andreas.dilger@intel.com>,
Oleg Drokin <oleg.drokin@intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Lustre Development List <lustre-devel@lists.lustre.org>
Subject: [lustre-devel] [PATCH 13/17] staging: lustre: lloop: Fix build failure on ppc64
Date: Sun, 10 Apr 2016 17:13:36 -0400 [thread overview]
Message-ID: <570AC200.2020401@suse.com> (raw)
In-Reply-To: <alpine.LFD.2.20.1604101500520.32661@casper.infradead.org>
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: OpenPGP digital signature
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20160410/73b49b73/attachment.pgp>
WARNING: multiple messages have this Message-ID (diff)
From: Jeff Mahoney <jeffm@suse.com>
To: James Simmons <jsimmons@infradead.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
devel@driverdev.osuosl.org,
Andreas Dilger <andreas.dilger@intel.com>,
Oleg Drokin <oleg.drokin@intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Lustre Development List <lustre-devel@lists.lustre.org>
Subject: Re: [PATCH 13/17] staging: lustre: lloop: Fix build failure on ppc64
Date: Sun, 10 Apr 2016 17:13:36 -0400 [thread overview]
Message-ID: <570AC200.2020401@suse.com> (raw)
In-Reply-To: <alpine.LFD.2.20.1604101500520.32661@casper.infradead.org>
[-- Attachment #1.1: Type: text/plain, Size: 2666 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
next prev parent reply other threads:[~2016-04-10 21:13 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-10 13:13 [lustre-devel] [PATCH 00/17] staging : lustre : rest of missing patches from 2.5.0 release James Simmons
2016-04-10 13:13 ` James Simmons
2016-04-10 13:13 ` [lustre-devel] [PATCH 01/17] staging: lustre: osc: fix race issues thanks to oap_lock James Simmons
2016-04-10 13:13 ` James Simmons
2016-04-12 4:05 ` [lustre-devel] " Greg Kroah-Hartman
2016-04-12 4:05 ` Greg Kroah-Hartman
2016-04-10 13:13 ` [lustre-devel] [PATCH 02/17] staging: lustre: clio: incorrect assertions in 'enable-invariants' James Simmons
2016-04-10 13:13 ` James Simmons
2016-04-10 13:13 ` [lustre-devel] [PATCH 03/17] staging: lustre: ldlm: Fix a race during FLock handling James Simmons
2016-04-10 13:13 ` James Simmons
2016-04-10 13:13 ` [lustre-devel] [PATCH 04/17] staging: lustre: ldlm: refine LU-2665 patch for POSIX compliance James Simmons
2016-04-10 13:13 ` James Simmons
2016-04-10 13:13 ` [lustre-devel] [PATCH 05/17] staging: lustre: llite: variable rename in namei.c James Simmons
2016-04-10 13:13 ` James Simmons
2016-04-10 13:13 ` [lustre-devel] [PATCH 06/17] staging: lustre: llite: speedup in unlink/rmdir James Simmons
2016-04-10 13:13 ` James Simmons
2016-04-10 13:13 ` [lustre-devel] [PATCH 07/17] staging: lustre: llite: error setting max_cache_mb at mount time James Simmons
2016-04-10 13:13 ` James Simmons
2016-04-10 13:13 ` [lustre-devel] [PATCH 08/17] staging: lustre: obd: MDT mount fails on MDS w/o MGS on it James Simmons
2016-04-10 13:13 ` James Simmons
2016-04-10 13:13 ` [lustre-devel] [PATCH 09/17] staging: lustre: ptlrpc: return a meaningful status from ptlrpcd_init() James Simmons
2016-04-10 13:13 ` James Simmons
2016-04-10 13:13 ` [lustre-devel] [PATCH 10/17] staging: lustre: llite: Truncate to restore file James Simmons
2016-04-10 13:13 ` James Simmons
2016-04-10 13:13 ` [lustre-devel] [PATCH 11/17] staging: lustre: osc: osc_extent_wait() shouldn't be interruptible James Simmons
2016-04-10 13:13 ` James Simmons
2016-04-10 13:13 ` [lustre-devel] [PATCH 12/17] staging: lustre: lprocfs: implement log2 using bitops James Simmons
2016-04-10 13:13 ` James Simmons
2016-04-10 13:13 ` [lustre-devel] [PATCH 13/17] staging: lustre: lloop: Fix build failure on ppc64 James Simmons
2016-04-10 13:13 ` James Simmons
2016-04-10 13:22 ` [lustre-devel] " Jeff Mahoney
2016-04-10 13:22 ` Jeff Mahoney
2016-04-10 14:04 ` [lustre-devel] " James Simmons
2016-04-10 14:04 ` James Simmons
2016-04-10 15:35 ` [lustre-devel] " Greg Kroah-Hartman
2016-04-10 15:35 ` Greg Kroah-Hartman
2016-04-10 15:52 ` [lustre-devel] " James Simmons
2016-04-10 15:52 ` James Simmons
2016-04-10 21:13 ` Jeff Mahoney [this message]
2016-04-10 21:13 ` Jeff Mahoney
2016-04-10 13:13 ` [lustre-devel] [PATCH 14/17] staging: lustre: lov: return minimal FIEMAP for released files James Simmons
2016-04-10 13:13 ` James Simmons
2016-04-10 13:13 ` [lustre-devel] [PATCH 15/17] staging: lustre: lov: Don't wait for active target with OBD_STATFS_NODELAY James Simmons
2016-04-10 13:13 ` James Simmons
2016-04-10 13:13 ` [lustre-devel] [PATCH 16/17] staging: lustre: hsm: permission checks for HSM ioctl operations James Simmons
2016-04-10 13:13 ` James Simmons
2016-04-10 13:13 ` [lustre-devel] [PATCH 17/17] staging: lustre: hsm: don't use real suppgid James Simmons
2016-04-10 13:13 ` James Simmons
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=570AC200.2020401@suse.com \
--to=jeffm@suse.com \
--cc=andreas.dilger@intel.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=jsimmons@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lustre-devel@lists.lustre.org \
--cc=oleg.drokin@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.