Hi,
I'm trying to test the btrfs and ceph contributions to 3.11, without
testing all of 3.11-rc1 (just yet), so I'm testing with the "next"
branch of Chris Mason's tree (commit cbacd76bb3 from
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git)
merged into the for-linus branch
Hi,
I'm trying to test the btrfs and ceph contributions to 3.11, without
testing all of 3.11-rc1 (just yet), so I'm testing with the next
branch of Chris Mason's tree (commit cbacd76bb3 from
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git)
merged into the for-linus branch of
On 05/30/2013 02:26 PM, Chuck Lever wrote:
>
> On May 30, 2013, at 4:19 PM, Jim Schutt wrote:
>
>> Hi,
>>
>> I've been trying to test 3.10-rc3 on some diskless clients, and found
>> that I can no longer mount my root file system via NFSv3.
>>
>
Hi,
I've been trying to test 3.10-rc3 on some diskless clients, and found
that I can no longer mount my root file system via NFSv3.
I poked around looking at NFS changes for 3.10, and found these two
commits:
d497ab9751 "NFSv3: match sec= flavor against server list"
4580a92d44 "NFS: Use
Hi,
I've been trying to test 3.10-rc3 on some diskless clients, and found
that I can no longer mount my root file system via NFSv3.
I poked around looking at NFS changes for 3.10, and found these two
commits:
d497ab9751 NFSv3: match sec= flavor against server list
4580a92d44 NFS: Use
On 05/30/2013 02:26 PM, Chuck Lever wrote:
On May 30, 2013, at 4:19 PM, Jim Schutt jasc...@sandia.gov wrote:
Hi,
I've been trying to test 3.10-rc3 on some diskless clients, and found
that I can no longer mount my root file system via NFSv3.
3.10-rc3 appears to be missing the fix
On 05/15/2013 10:49 AM, Alex Elder wrote:
> On 05/15/2013 11:38 AM, Jim Schutt wrote:
>> > Ceph's encode_caps_cb() worked hard to not call __page_cache_alloc() while
>> > holding a lock, but it's spoiled because ceph_pagelist_addpage() always
>> > calls kmap
: mds0 reconnect success
[13490.720032] ceph: mds0 caps stale
[13501.235257] ceph: mds0 recovery completed
[13501.300419] ceph: mds0 caps renewed
Fix it up by encoding locks into a buffer first, and when the
number of encoded locks is stable, copy that into a ceph_pagelist.
Signed-off-by: Jim Schu
and
src/include/encoding.h in the Ceph server code (git://github.com/ceph/ceph).
I also checked the server side for flock_len decoding, and I believe that
also happens correctly, by virtue of having been declared __le32 in
struct ceph_mds_cap_reconnect, in src/include/ceph_fs.h.
Signed-off-by: Jim
Signed-off-by: Jim Schutt
---
fs/ceph/locks.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/ceph/locks.c b/fs/ceph/locks.c
index 202dd3d..ffc86cb 100644
--- a/fs/ceph/locks.c
+++ b/fs/ceph/locks.c
@@ -169,7 +169,7 @@ int ceph_flock(struct file *file, int cmd
/include/ceph_fs.h.
Jim Schutt (3):
ceph: fix up comment for ceph_count_locks() as to which lock to hold
ceph: add missing cpu_to_le32() calls when encoding a reconnect capability
ceph: ceph_pagelist_append might sleep while atomic
fs/ceph/locks.c | 75
/include/ceph_fs.h.
Jim Schutt (3):
ceph: fix up comment for ceph_count_locks() as to which lock to hold
ceph: add missing cpu_to_le32() calls when encoding a reconnect capability
ceph: ceph_pagelist_append might sleep while atomic
fs/ceph/locks.c | 75
Signed-off-by: Jim Schutt jasc...@sandia.gov
---
fs/ceph/locks.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/ceph/locks.c b/fs/ceph/locks.c
index 202dd3d..ffc86cb 100644
--- a/fs/ceph/locks.c
+++ b/fs/ceph/locks.c
@@ -169,7 +169,7 @@ int ceph_flock(struct file
and
src/include/encoding.h in the Ceph server code (git://github.com/ceph/ceph).
I also checked the server side for flock_len decoding, and I believe that
also happens correctly, by virtue of having been declared __le32 in
struct ceph_mds_cap_reconnect, in src/include/ceph_fs.h.
Signed-off-by: Jim
success
[13490.720032] ceph: mds0 caps stale
[13501.235257] ceph: mds0 recovery completed
[13501.300419] ceph: mds0 caps renewed
Fix it up by encoding locks into a buffer first, and when the
number of encoded locks is stable, copy that into a ceph_pagelist.
Signed-off-by: Jim Schutt jasc...@sandia.gov
On 05/15/2013 10:49 AM, Alex Elder wrote:
On 05/15/2013 11:38 AM, Jim Schutt wrote:
Ceph's encode_caps_cb() worked hard to not call __page_cache_alloc() while
holding a lock, but it's spoiled because ceph_pagelist_addpage() always
calls kmap(), which might sleep. Here's the result
On 05/14/2013 10:44 AM, Alex Elder wrote:
> On 05/09/2013 09:42 AM, Jim Schutt wrote:
>> Ceph's encode_caps_cb() worked hard to not call __page_cache_alloc while
>> holding a lock, but it's spoiled because ceph_pagelist_addpage() always
>> calls kmap(), which might slee
On 05/14/2013 10:44 AM, Alex Elder wrote:
On 05/09/2013 09:42 AM, Jim Schutt wrote:
Ceph's encode_caps_cb() worked hard to not call __page_cache_alloc while
holding a lock, but it's spoiled because ceph_pagelist_addpage() always
calls kmap(), which might sleep. Here's the result:
I finally
: mds0 reconnect success
[13490.720032] ceph: mds0 caps stale
[13501.235257] ceph: mds0 recovery completed
[13501.300419] ceph: mds0 caps renewed
Fix it up by encoding locks into a buffer first, and when the
number of encoded locks is stable, copy that into a ceph_pagelist.
Signed-off-by: Jim Schu
success
[13490.720032] ceph: mds0 caps stale
[13501.235257] ceph: mds0 recovery completed
[13501.300419] ceph: mds0 caps renewed
Fix it up by encoding locks into a buffer first, and when the
number of encoded locks is stable, copy that into a ceph_pagelist.
Signed-off-by: Jim Schutt jasc...@sandia.gov
On 12/11/2012 06:37 PM, Liu Bo wrote:
> On Tue, Dec 11, 2012 at 09:33:15AM -0700, Jim Schutt wrote:
>> On 12/09/2012 07:04 AM, Liu Bo wrote:
>>> On Wed, Dec 05, 2012 at 09:07:05AM -0700, Jim Schutt wrote:
>>> Hi Jim,
>>>
>>> Could you please apply the
On 12/11/2012 06:37 PM, Liu Bo wrote:
On Tue, Dec 11, 2012 at 09:33:15AM -0700, Jim Schutt wrote:
On 12/09/2012 07:04 AM, Liu Bo wrote:
On Wed, Dec 05, 2012 at 09:07:05AM -0700, Jim Schutt wrote:
Hi Jim,
Could you please apply the following patch to test if it works?
Hi,
So far
On 12/09/2012 07:04 AM, Liu Bo wrote:
> On Wed, Dec 05, 2012 at 09:07:05AM -0700, Jim Schutt wrote:
>> > Hi,
>> >
>> > I'm hitting a btrfs locking issue with 3.7.0-rc8.
>> >
>> > The btrfs filesystem in question is backing a Ceph OSD
>&g
On 12/09/2012 07:04 AM, Liu Bo wrote:
On Wed, Dec 05, 2012 at 09:07:05AM -0700, Jim Schutt wrote:
Hi,
I'm hitting a btrfs locking issue with 3.7.0-rc8.
The btrfs filesystem in question is backing a Ceph OSD
under a heavy write load from many cephfs clients.
I reported
On 12/05/2012 09:07 AM, Jim Schutt wrote:
Hi,
I'm hitting a btrfs locking issue with 3.7.0-rc8.
The btrfs filesystem in question is backing a Ceph OSD
under a heavy write load from many cephfs clients.
I reported this issue a while ago:
http://www.spinics.net/lists/linux-btrfs/msg19370.html
On 12/05/2012 09:07 AM, Jim Schutt wrote:
Hi,
I'm hitting a btrfs locking issue with 3.7.0-rc8.
The btrfs filesystem in question is backing a Ceph OSD
under a heavy write load from many cephfs clients.
I reported this issue a while ago:
http://www.spinics.net/lists/linux-btrfs/msg19370.html
Hi,
I'm hitting a btrfs locking issue with 3.7.0-rc8.
The btrfs filesystem in question is backing a Ceph OSD
under a heavy write load from many cephfs clients.
I reported this issue a while ago:
http://www.spinics.net/lists/linux-btrfs/msg19370.html
when I was testing what I thought might be
Hi,
I'm hitting a btrfs locking issue with 3.7.0-rc8.
The btrfs filesystem in question is backing a Ceph OSD
under a heavy write load from many cephfs clients.
I reported this issue a while ago:
http://www.spinics.net/lists/linux-btrfs/msg19370.html
when I was testing what I thought might be
Hi Mel,
On 08/12/2012 02:22 PM, Mel Gorman wrote:
I went through the patch again but only found the following which is a
weak candidate. Still, can you retest with the following patch on top and
CONFIG_PROVE_LOCKING set please?
I've gotten in several hours of testing on this patch with
no
Hi Mel,
On 08/12/2012 02:22 PM, Mel Gorman wrote:
I went through the patch again but only found the following which is a
weak candidate. Still, can you retest with the following patch on top and
CONFIG_PROVE_LOCKING set please?
I've gotten in several hours of testing on this patch with
no
On 08/10/2012 05:02 AM, Mel Gorman wrote:
On Thu, Aug 09, 2012 at 04:38:24PM -0600, Jim Schutt wrote:
Ok, this is an untested hack and I expect it would drop allocation success
rates again under load (but not as much). Can you test again and see what
effect, if any, it has please?
---8
On 08/10/2012 05:02 AM, Mel Gorman wrote:
On Thu, Aug 09, 2012 at 04:38:24PM -0600, Jim Schutt wrote:
Ok, this is an untested hack and I expect it would drop allocation success
rates again under load (but not as much). Can you test again and see what
effect, if any, it has please?
---8
On 08/09/2012 02:46 PM, Mel Gorman wrote:
On Thu, Aug 09, 2012 at 12:16:35PM -0600, Jim Schutt wrote:
On 08/09/2012 07:49 AM, Mel Gorman wrote:
Changelog since V2
o Capture !MIGRATE_MOVABLE pages where possible
o Document the treatment of MIGRATE_MOVABLE pages while capturing
o Expand
der load -
to 0% in one case. There is a proposed change to that patch in this series
and it would be ideal if Jim Schutt could retest the workload that led to
commit [7db8889a: mm: have order> 0 compaction start off where it left].
On my first test of this patch series on top of 3.5,
ess rates under load -
to 0% in one case. There is a proposed change to that patch in this series
and it would be ideal if Jim Schutt could retest the workload that led to
commit [7db8889a: mm: have order> 0 compaction start off where it left].
I was successful at resolving my Ceph issue on 3
under load -
to 0% in one case. There is a proposed change to that patch in this series
and it would be ideal if Jim Schutt could retest the workload that led to
commit [7db8889a: mm: have order 0 compaction start off where it left].
I was successful at resolving my Ceph issue on 3.6-rc1
load -
to 0% in one case. There is a proposed change to that patch in this series
and it would be ideal if Jim Schutt could retest the workload that led to
commit [7db8889a: mm: have order 0 compaction start off where it left].
On my first test of this patch series on top of 3.5, I ran
On 08/09/2012 02:46 PM, Mel Gorman wrote:
On Thu, Aug 09, 2012 at 12:16:35PM -0600, Jim Schutt wrote:
On 08/09/2012 07:49 AM, Mel Gorman wrote:
Changelog since V2
o Capture !MIGRATE_MOVABLE pages where possible
o Document the treatment of MIGRATE_MOVABLE pages while capturing
o Expand
On 08/07/2012 08:52 AM, Mel Gorman wrote:
On Tue, Aug 07, 2012 at 10:45:25AM -0400, Rik van Riel wrote:
On 08/07/2012 08:31 AM, Mel Gorman wrote:
commit [7db8889a: mm: have order> 0 compaction start off where it left]
introduced a caching mechanism to reduce the amount work the free page
On 08/07/2012 08:52 AM, Mel Gorman wrote:
On Tue, Aug 07, 2012 at 10:45:25AM -0400, Rik van Riel wrote:
On 08/07/2012 08:31 AM, Mel Gorman wrote:
commit [7db8889a: mm: have order 0 compaction start off where it left]
introduced a caching mechanism to reduce the amount work the free page
On Thu, 2006-11-23 at 12:24 +0100, Jens Axboe wrote:
> On Wed, Nov 22 2006, Jim Schutt wrote:
> >
> > On Wed, 2006-11-22 at 09:57 +0100, Jens Axboe wrote:
> > > On Tue, Nov 21 2006, Jim Schutt wrote:
> > [snip]
> > > >
> > > >
On Thu, 2006-11-23 at 12:24 +0100, Jens Axboe wrote:
On Wed, Nov 22 2006, Jim Schutt wrote:
On Wed, 2006-11-22 at 09:57 +0100, Jens Axboe wrote:
On Tue, Nov 21 2006, Jim Schutt wrote:
[snip]
Hmmm. Is it worth me trying to do some sort of kernel
profiling to see
On Thu, 2006-11-16 at 21:25 +0100, Jens Axboe wrote:
> On Thu, Nov 16 2006, Jim Schutt wrote:
> > Hi,
> >
> > My test program can do one of the following:
> >
> > send data:
> > A) read() from file into buffer, write() buffer into socket
> > B) mma
On Thu, 2006-11-16 at 21:25 +0100, Jens Axboe wrote:
On Thu, Nov 16 2006, Jim Schutt wrote:
Hi,
My test program can do one of the following:
send data:
A) read() from file into buffer, write() buffer into socket
B) mmap() section of file, write() that into socket, munmap()
C
On Thu, 2006-11-16 at 21:25 +0100, Jens Axboe wrote:
> On Thu, Nov 16 2006, Jim Schutt wrote:
> > Hi,
> >
> >
> > My test program can do one of the following:
> >
> > send data:
> > A) read() from file into buffer, write() buffer into
is read+write really the fastest way to get data off a
socket and into a file?
-- Jim Schutt
(Please Cc: me, as I'm not subscribed to lkml.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger
to get data off a
socket and into a file?
-- Jim Schutt
(Please Cc: me, as I'm not subscribed to lkml.)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
On Thu, 2006-11-16 at 21:25 +0100, Jens Axboe wrote:
On Thu, Nov 16 2006, Jim Schutt wrote:
Hi,
My test program can do one of the following:
send data:
A) read() from file into buffer, write() buffer into socket
B) mmap() section of file, write() that into socket, munmap
bet that helps
It does -- no more spurious interrupts.
Thanks -- Jim
--
Jim Schutt <[EMAIL PROTECTED]>
Sandia National Laboratories, Albuquerque, New Mexico USA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
available on request.
Thanks -- Jim
--
Jim Schutt <[EMAIL PROTECTED]>
Sandia National Laboratories, Albuquerque, New Mexico USA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://
spurious interrupts.
Thanks -- Jim
--
Jim Schutt [EMAIL PROTECTED]
Sandia National Laboratories, Albuquerque, New Mexico USA
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
Jeff Garzik wrote:
>
>
> de4x5 is becoming EISA-only in 2.5.x too, since its PCI support is
> duplicated now in tulip driver.
>
I've got some DEC Miatas with DECchip 21142/43 ethernet cards, and I
don't get the same link speeds when using the de4x5 and tulip drivers,
as of 2.4.0-test10. The
Jeff Garzik wrote:
de4x5 is becoming EISA-only in 2.5.x too, since its PCI support is
duplicated now in tulip driver.
I've got some DEC Miatas with DECchip 21142/43 ethernet cards, and I
don't get the same link speeds when using the de4x5 and tulip drivers,
as of 2.4.0-test10. The
53 matches
Mail list logo
