Re: arcmsr areca-1660 - strange behaviour under heavy load
Hi On Sun, 24 Feb 2008, Andrew Morton wrote: Hi Andrew, thanks a lot for reply, I'm attaching requested information. please let me know if You need more information/testing, whatever. I'll be glad to help. BR nik Areca support doesn't seem to be very interested in the problem :-( (cc's added) Please get the machine into this state of memory exhaustion then take copies of the output of the following, and send them via reply-to-all to this email: - cat /proc/meminfo - cat /proc/slabinfo - dmesg -c /dev/null ; echo m /proc/sysrq-trigger ; dmesg -c Thanks. -- 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 read the FAQ at http://www.tux.org/lkml/ -- MemTotal: 188464 kB MemFree: 82268 kB Buffers: 20572 kB Cached: 40312 kB SwapCached: 1508 kB Active: 35220 kB Inactive:29436 kB SwapTotal: 3145712 kB SwapFree: 3142156 kB Dirty: 340 kB Writeback: 0 kB AnonPages:2836 kB Mapped: 4532 kB Slab:29824 kB SReclaimable:16728 kB SUnreclaim: 13096 kB PageTables: 1024 kB NFS_Unstable:0 kB Bounce: 0 kB CommitLimit: 3239944 kB Committed_AS:13732 kB VmallocTotal: 34359738367 kB VmallocUsed: 10644 kB VmallocChunk: 34359727343 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB slabinfo - version: 2.1 # nameactive_objs num_objs objsize objperslab pagesperslab : tunables limit batchcount sharedfactor : slabdata active_slabs num_slabs sharedavail fib6_nodes 5 59 64 591 : tunables 120 608 : slabdata 1 1 0 ip6_dst_cache 4 12320 121 : tunables 54 278 : slabdata 1 1 0 ndisc_cache1 15256 151 : tunables 120 608 : slabdata 1 1 0 RAWv6 11 1289641 : tunables 54 278 : slabdata 3 3 0 UDPLITEv6 0 089641 : tunables 54 278 : slabdata 0 0 0 UDPv6 0 089641 : tunables 54 278 : slabdata 0 0 0 tw_sock_TCPv6 0 0192 201 : tunables 120 608 : slabdata 0 0 0 request_sock_TCPv6 0 0192 201 : tunables 120 608 : slabdata 0 0 0 TCPv6 2 4 166442 : tunables 24 128 : slabdata 1 1 0 ip_fib_alias 10 59 64 591 : tunables 120 608 : slabdata 1 1 0 ip_fib_hash 10 59 64 591 : tunables 120 608 : slabdata 1 1 0 reiser_inode_cache 13 1577651 : tunables 54 278 : slabdata 3 3 0 dm_mpath_io0 0 40 921 : tunables 120 608 : slabdata 0 0 0 dm_snap_pending_exception128136112 341 : tunables 120 60 8 : slabdata 4 4 0 dm_snap_exception 0 0 32 1121 : tunables 120 608 : slabdata 0 0 0 dm_uevent 0 0 260832 : tunables 24 128 : slabdata 0 0 0 dm_target_io1320 1440 24 1441 : tunables 120 608 : slabdata 10 10 0 dm_io 1320 1472 40 921 : tunables 120 608 : slabdata 16 16 0 scsi_cmd_cache38 40384 101 : tunables 54 278 : slabdata 4 4 0 sgpool-128 2 2 409611 : tunables 24 128 : slabdata 2 2 0 sgpool-64 2 2 204821 : tunables 24 128 : slabdata 1 1 0 sgpool-32 2 4 102441 : tunables 54 278 : slabdata 1 1 0 sgpool-16 3 851281 : tunables 54 278 : slabdata 1 1 0 sgpool-8 13 45256 151 : tunables 120 608 : slabdata 3 3 0 scsi_io_context0 0112 341 : tunables 120 608 : slabdata 0 0 0 ext3_inode_cache3946 402883241 : tunables 54 278 : slabdata 1007 1007 0 ext3_xattr 0 0 88 441 : tunables 120 608 : slabdata 0 0 0 journal_handle32144 24 1441 : tunables 120 608 : slabdata 1 1 0 journal_head 105280 96 401 : tunables 120 608 : slabdata 7 7 0 revoke_table 6202 16 2021 : tunables 120 608 : slabdata 1 1 0
RE: arcmsr areca-1660 - strange behaviour under heavy load
Hi Nikola, As I said, we will test on our site. Our support team will help you to settle the issue. Sorry for your inconvenience, -Original Message- From: Nikola Ciprich [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 5:36 PM To: Andrew Morton Cc: [EMAIL PROTECTED]; linux-scsi@vger.kernel.org; Nick Cheng; Erich Chen; [EMAIL PROTECTED] Subject: Re: arcmsr areca-1660 - strange behaviour under heavy load Hi On Sun, 24 Feb 2008, Andrew Morton wrote: Hi Andrew, thanks a lot for reply, I'm attaching requested information. please let me know if You need more information/testing, whatever. I'll be glad to help. BR nik Areca support doesn't seem to be very interested in the problem :-( (cc's added) Please get the machine into this state of memory exhaustion then take copies of the output of the following, and send them via reply-to-all to this email: - cat /proc/meminfo - cat /proc/slabinfo - dmesg -c /dev/null ; echo m /proc/sysrq-trigger ; dmesg -c Thanks. -- 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 read the FAQ at http://www.tux.org/lkml/ -- - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [3/22] Remove unchecked_isa_dma in advansys.c
On Mon, Feb 25, 2008 at 11:40:35PM +0100, Andi Kleen wrote: On Mon, Feb 25, 2008 at 02:47:46PM -0700, Matthew Wilcox wrote: I have to say I really don't like this patch. I'll look up my current Why do you not like it? What would you do better? patch queue for this driver next week -- I think I fixed this differently. (I must have fixed it somehow because it works on parisc, which is most unforgiving of drivers which do DMA without the DMA API). This patch is unnecessary. The driver does not access the cmnd field using DMA. See AscPutReadyQueue where it calls: AscMemWordCopyPtrToLram(iop_base, q_addr + ASC_SCSIQ_CDB_BEG, (uchar *)scsiq-cdbptr, scsiq-q2.cdb_len 1); Despite the name, it doesn't actually copy a pointer to Lram. It copies the thing pointed at to Lram. (ie it's memcpy_toio with a minor twist). -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Advansys regression between 2.6.23.8 and 2.6.24.2
Hi James, Le Thu, 14 Feb 2008 09:50:58 -0600, James Bottomley [EMAIL PROTECTED] a écrit : Yes, it's already on its way to stable. The process requires the fix to be committed upstream first. There's an automated script that sends these commits back to stable once they're upstream (provided they're tagged correctly). I might be wrong, but I don't see this patch in 2.6.24.3, which has just been released. Sincerly, Thomas -- Thomas Petazzoni, Free Electrons Free Embedded Linux Training Materials on http://free-electrons.com/training (More than 1500 pages!) signature.asc Description: PGP signature
Re: [PATCH] [3/22] Remove unchecked_isa_dma in advansys.c
On Tue, 2008-02-26 at 04:44 +0100, Andi Kleen wrote: On Mon, Feb 25, 2008 at 03:50:22PM -0700, Matthew Wilcox wrote: On Mon, Feb 25, 2008 at 11:40:35PM +0100, Andi Kleen wrote: (I must have fixed it somehow because it works on parisc, which is most unforgiving of drivers which do DMA without the DMA API). At least on x86 the DMA API cannot do ISA bouncing. You're saying that if I set a 24-bit DMA mask, and then do a pci_alloc_coherent(), x86 might hand me back something that's not accessible? That would be just broken. No pci_alloc_coherent works, but pci_map_* will not. Yes, it does ... dma_map is a flush/virt_to_phys on x86. so of course it works. If you mean it doesn't transform from 24 bit phys to 24 bit phys, then yes; but that's not an API requirement; that's what bounce buffering is all about, so for ISA devices we always only call dma_map on 24 bit phys addresses and it all works. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Patch added to scsi-rc-fixes-2.6: [SCSI] arcmsr: fix messageallocation
On Tue, 2008-02-26 at 12:29 +0800, nickcheng wrote: James, Appreciate for your answer. One more question: do you think there are any compatibility issues on kmalloc/kfree pair? I just trace the kernel code. It looks like it would not. But I am not quite sure absolutely. May I have your comments? You mean does kmalloc/kfree obey the same rules as the coherent allocators in all regards except coherence ... pretty much, yes. There are some technical differences at the bottom in terms of page alignment, but nothing you need to worry about. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: arcmsr areca-1660 - strange behaviour under heavy load
On Tue, 26 Feb 2008 10:35:31 +0100 (CET) Nikola Ciprich [EMAIL PROTECTED] wrote: Hi On Sun, 24 Feb 2008, Andrew Morton wrote: Hi Andrew, thanks a lot for reply, I'm attaching requested information. please let me know if You need more information/testing, whatever. I'll be glad to help. BR nik Areca support doesn't seem to be very interested in the problem :-( (cc's added) Please get the machine into this state of memory exhaustion then take copies of the output of the following, and send them via reply-to-all to this email: - cat /proc/meminfo - cat /proc/slabinfo - dmesg -c /dev/null ; echo m /proc/sysrq-trigger ; dmesg -c Thanks. Alas, that all looks OK to me. You never get any out-of-memory messages, and no oom-killing messages? Possibly what is happening here is that in this low-memory condition, some of the driver's internal memory-allocation attempts are failing, and the driver isn't correctly handling this. This is a rare situation which may well not have been hit in anyone else's testing. I expect that the Areca engineers will be able to reproduce this with a suitably small mem= kernel boot option. If not, they could perhaps investigate the kernel's fault-injection framework, which permits simulation of page allocation failures. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Performance problems with 3ware 9500S-4LP and 2.6.25-rc3
Hello Andre, On Tuesday 26 February 2008 18:43:14 Andre Noll wrote: Hi we are experiencing massive performance problems with two of our Linux servers that contain 3ware controllers on a Tyan mainboard and a couple of 1T disks. During the daily cron job that uses rsync to sync a 500G file system from another machine to the raid on the 3ware controller the load jumps up, and the machine becomes sluggish as hell. For example, an ssh login to that machine takes minutes to complete and ldap becomes unreliable while the rsync job is running. Even Nagios complains about the machine being down while rsync is running. do you have the write-back cache of the controller enabled for your disks? When you disable this cache, the controller will also disable the disks, cause a write-performance between 3 to 8MB/s per disks. Cheers, Bernd -- Bernd Schubert Q-Leap Networks GmbH - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] (was Re: [ofa-general] fmr pool free_list empty)
[EMAIL PROTECTED] wrote on Mon, 25 Feb 2008 15:02 -0800: Ugh. [pw wrote:] Looking at the FMR dirty list unmapping code in ib_fmr_batch_release(), there is a section that pulls all the dirty entries onto a list that it will later unmap and put back on the free list. But it also plans to unmap all the free entries that have ever been remapped: Yes, this came from a3cd7d90 (IB/fmr_pool: ib_fmr_pool_flush() should flush all dirty FMRs). That solved a real problem for Olaf, because otherwise dirty FMRs with not at the max map count might never get invalidated. It's not exactly an optimization but rather a correctness issue, because RDS relies on killing mapping eventually. On the other hand, this behavior clearly does lead to the possibility of leaving the free list temporarily empty for stupid reasons. I don't see a really good way to fix this at the momemnt, need to meditate a little. Adding CCs in case some iser users are not on the openfabrics list. Original message is here: http://lists.openfabrics.org/pipermail/general/2008-February/047111.html This quoted commit is a regression for iSER. Not sure if it causes problems for the other FMR user, SRP. It went in after v2.6.24. Following this mail are two patches. One to revert the change, and one to attempt to do Olaf's patch in such a way that it does not cause problems for other FMR users. I haven't tested the patches with RDS. It apparently isn't in the tree yet. In fact, there are no users of ib_flush_fmr_pool() in the tree, which is the only function affected by the second patch. But iSER is working again in my scenario. As a side note, I don't remember seeing this patch on the openfabrics mailing list. Perhaps I missed it. Sometimes these sorts of interactions can be spotted if proposed changes get wider attention. -- Pete - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Revert IB/fmr_pool: ib_fmr_pool_flush() should flush all dirty FMRs
This reverts commit a3cd7d9070be417a21905c997ee32d756d999b38.
The original commit breaks iSER reliably, making it complain:
iser: iser_reg_page_vec:ib_fmr_pool_map_phys failed: -11
The FMR cleanup thread runs ib_fmr_batch_release() as dirty
entries build up. This commit causes clean but used FMR
entries also to be purged. During that process, another thread
can see that there are no free FMRs and fail, even though
there should always have been enough available.
Signed-off-by: Pete Wyckoff [EMAIL PROTECTED]
---
drivers/infiniband/core/fmr_pool.c | 21 ++---
1 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/drivers/infiniband/core/fmr_pool.c
b/drivers/infiniband/core/fmr_pool.c
index 7f00347..4044fdf 100644
--- a/drivers/infiniband/core/fmr_pool.c
+++ b/drivers/infiniband/core/fmr_pool.c
@@ -139,7 +139,7 @@ static inline struct ib_pool_fmr
*ib_fmr_cache_lookup(struct ib_fmr_pool *pool,
static void ib_fmr_batch_release(struct ib_fmr_pool *pool)
{
int ret;
- struct ib_pool_fmr *fmr, *next;
+ struct ib_pool_fmr *fmr;
LIST_HEAD(unmap_list);
LIST_HEAD(fmr_list);
@@ -158,20 +158,6 @@ static void ib_fmr_batch_release(struct ib_fmr_pool *pool)
#endif
}
- /*
-* The free_list may hold FMRs that have been put there
-* because they haven't reached the max_remap count.
-* Invalidate their mapping as well.
-*/
- list_for_each_entry_safe(fmr, next, pool-free_list, list) {
- if (fmr-remap_count == 0)
- continue;
- hlist_del_init(fmr-cache_node);
- fmr-remap_count = 0;
- list_add_tail(fmr-fmr-list, fmr_list);
- list_move(fmr-list, unmap_list);
- }
-
list_splice(pool-dirty_list, unmap_list);
INIT_LIST_HEAD(pool-dirty_list);
pool-dirty_len = 0;
@@ -384,6 +370,11 @@ void ib_destroy_fmr_pool(struct ib_fmr_pool *pool)
i = 0;
list_for_each_entry_safe(fmr, tmp, pool-free_list, list) {
+ if (fmr-remap_count) {
+ INIT_LIST_HEAD(fmr_list);
+ list_add_tail(fmr-fmr-list, fmr_list);
+ ib_unmap_fmr(fmr_list);
+ }
ib_dealloc_fmr(fmr-fmr);
list_del(fmr-list);
kfree(fmr);
--
1.5.4.1
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ib fmr pool: flush used clean entries
Commit a3cd7d9070be417a21905c997ee32d756d999b38 (IB/fmr_pool:
ib_fmr_pool_flush() should flush all dirty FMRs) caused a
regression for iSER and was reverted in
e5507736c6449b3253347eed6f8ea77a28cf688e.
This change attempts to redo the original patch so that all used
FMR entries are flushed when ib_flush_fmr_pool() is called,
and other FMR users are not affected. Simply move used entries
from the clean list onto the dirty list before letting the
cleanup thread do its job.
Signed-off-by: Pete Wyckoff [EMAIL PROTECTED]
---
drivers/infiniband/core/fmr_pool.c | 17 -
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/core/fmr_pool.c
b/drivers/infiniband/core/fmr_pool.c
index 4044fdf..06d502c 100644
--- a/drivers/infiniband/core/fmr_pool.c
+++ b/drivers/infiniband/core/fmr_pool.c
@@ -398,8 +398,23 @@ EXPORT_SYMBOL(ib_destroy_fmr_pool);
*/
int ib_flush_fmr_pool(struct ib_fmr_pool *pool)
{
- int serial = atomic_inc_return(pool-req_ser);
+ int serial;
+ struct ib_pool_fmr *fmr, *next;
+
+ /*
+* The free_list holds FMRs that may have been used
+* but have not been remapped enough times to be dirty.
+* Put them on the dirty list now so that the cleanup
+* thread will reap them too.
+*/
+ spin_lock_irq(pool-pool_lock);
+ list_for_each_entry_safe(fmr, next, pool-free_list, list) {
+ if (fmr-remap_count 0)
+ list_move(fmr-list, pool-dirty_list);
+ }
+ spin_unlock_irq(pool-pool_lock);
+ serial = atomic_inc_return(pool-req_ser);
wake_up_process(pool-thread);
if (wait_event_interruptible(pool-force_wait,
--
1.5.4.1
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Performance problems with 3ware 9500S-4LP and 2.6.25-rc3
Andre Noll wrote: we are experiencing massive performance problems with two of our Linux servers that contain 3ware controllers on a Tyan mainboard and a couple of 1T disks. During the daily cron job that uses rsync to sync a 500G file system from another machine to the raid on the 3ware controller the load jumps up, and the machine becomes sluggish as hell. For example, an ssh login to that machine takes minutes to complete and ldap becomes unreliable while the rsync job is running. Even Nagios complains about the machine being down while rsync is running. You're putting your box under astronomical load. This is generally regarded as a bad idea, regardless of how well your storage controller is performing. Can you measure the single-threaded throughput (say, coping one huge file, and then syncing) to give us a baseline performance figure? rsync will happily peg your box, your network, and your cat if you let it. -- Chris - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] iscsi regression: check for zero max session cmds
From: Mike Christie [EMAIL PROTECTED]
The old tools did not set max session cmds. This is a regression.
I removed the check when merging the power of 2 patch.
Signed-off-by: Mike Christie [EMAIL PROTECTED]
---
drivers/scsi/libiscsi.c |4 ++--
drivers/scsi/scsi_transport_iscsi.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 59f8445..bdd7de7 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -1708,8 +1708,8 @@ iscsi_session_setup(struct iscsi_transport *iscsit,
qdepth = ISCSI_DEF_CMD_PER_LUN;
}
- if (!is_power_of_2(cmds_max) ||
- cmds_max = ISCSI_MGMT_ITT_OFFSET) {
+ if (!is_power_of_2(cmds_max) || cmds_max = ISCSI_MGMT_ITT_OFFSET ||
+ cmds_max 2) {
if (cmds_max != 0)
printk(KERN_ERR iscsi: invalid can_queue of %d.
can_queue must be a power of 2 and between
diff --git a/drivers/scsi/scsi_transport_iscsi.c
b/drivers/scsi/scsi_transport_iscsi.c
index 9981682..dfb026b 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -33,7 +33,7 @@
#define ISCSI_SESSION_ATTRS 19
#define ISCSI_CONN_ATTRS 13
#define ISCSI_HOST_ATTRS 4
-#define ISCSI_TRANSPORT_VERSION 2.0-868
+#define ISCSI_TRANSPORT_VERSION 2.0-869
struct iscsi_internal {
int daemon_pid;
--
1.5.1.2
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [3/22] Remove unchecked_isa_dma in advansys.c
On Tue, Feb 26, 2008 at 07:18:18AM -0800, James Bottomley wrote: On Tue, 2008-02-26 at 04:44 +0100, Andi Kleen wrote: No pci_alloc_coherent works, but pci_map_* will not. Yes, it does ... dma_map is a flush/virt_to_phys on x86. so of course it works. If you mean it doesn't transform from 24 bit phys to 24 bit phys, then yes; but that's not an API requirement; that's what bounce buffering is all about, so for ISA devices we always only call dma_map on 24 bit phys addresses and it all works. Actually, tomo's patch violates that ... asc_dvc_varp-overrun_buf = kzalloc(ASC_OVERRUN_BSIZE, GFP_KERNEL); [...] asc_dvc-overrun_dma = dma_map_single(board-dev, asc_dvc-overrun_buf, ASC_OVERRUN_BSIZE, DMA_FROM_DEVICE); There's a missing check for ISA boards and GFP_DMA. Honestly, I'd rather over-allocate asc_dvc_varp-overrun_buf by 4 bytes and map the appropriate alignment. Patch next week, probably. -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Revert IB/fmr_pool: ib_fmr_pool_flush() should flush all dirty FMRs
Pete, the subject says PATCH 1/2 but I didn't see any follow-up message
for PATCH 2/2. Just wondering :)
Benny
On Feb. 26, 2008, 10:27 -0800, Pete Wyckoff [EMAIL PROTECTED] wrote:
This reverts commit a3cd7d9070be417a21905c997ee32d756d999b38.
The original commit breaks iSER reliably, making it complain:
iser: iser_reg_page_vec:ib_fmr_pool_map_phys failed: -11
The FMR cleanup thread runs ib_fmr_batch_release() as dirty
entries build up. This commit causes clean but used FMR
entries also to be purged. During that process, another thread
can see that there are no free FMRs and fail, even though
there should always have been enough available.
Signed-off-by: Pete Wyckoff [EMAIL PROTECTED]
---
drivers/infiniband/core/fmr_pool.c | 21 ++---
1 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/drivers/infiniband/core/fmr_pool.c
b/drivers/infiniband/core/fmr_pool.c
index 7f00347..4044fdf 100644
--- a/drivers/infiniband/core/fmr_pool.c
+++ b/drivers/infiniband/core/fmr_pool.c
@@ -139,7 +139,7 @@ static inline struct ib_pool_fmr
*ib_fmr_cache_lookup(struct ib_fmr_pool *pool,
static void ib_fmr_batch_release(struct ib_fmr_pool *pool)
{
int ret;
- struct ib_pool_fmr *fmr, *next;
+ struct ib_pool_fmr *fmr;
LIST_HEAD(unmap_list);
LIST_HEAD(fmr_list);
@@ -158,20 +158,6 @@ static void ib_fmr_batch_release(struct ib_fmr_pool
*pool)
#endif
}
- /*
- * The free_list may hold FMRs that have been put there
- * because they haven't reached the max_remap count.
- * Invalidate their mapping as well.
- */
- list_for_each_entry_safe(fmr, next, pool-free_list, list) {
- if (fmr-remap_count == 0)
- continue;
- hlist_del_init(fmr-cache_node);
- fmr-remap_count = 0;
- list_add_tail(fmr-fmr-list, fmr_list);
- list_move(fmr-list, unmap_list);
- }
-
list_splice(pool-dirty_list, unmap_list);
INIT_LIST_HEAD(pool-dirty_list);
pool-dirty_len = 0;
@@ -384,6 +370,11 @@ void ib_destroy_fmr_pool(struct ib_fmr_pool *pool)
i = 0;
list_for_each_entry_safe(fmr, tmp, pool-free_list, list) {
+ if (fmr-remap_count) {
+ INIT_LIST_HEAD(fmr_list);
+ list_add_tail(fmr-fmr-list, fmr_list);
+ ib_unmap_fmr(fmr_list);
+ }
ib_dealloc_fmr(fmr-fmr);
list_del(fmr-list);
kfree(fmr);
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: arcmsr areca-1660 - strange behaviour under heavy load
Hi Andrew, no, right now I have the machine in the weird state, swap is empty (3GB), and so is bigger part of RAM (~100MB free), and the gcc crashes even when trying to compile c program with empty main function. so it doesn't seem to be problem with memory exhaustion. Hopefully the areca guys will be able to find out what is going on. But anyways, if You'll have any other idea what should I check/try, please let me know, as I have to admit that I'd really like to hunt it down myself (and yes, there is some vanity on my side here :)) thanks a lot once more cheers nik On Tue, 26 Feb 2008, Andrew Morton wrote: On Tue, 26 Feb 2008 10:35:31 +0100 (CET) Nikola Ciprich [EMAIL PROTECTED] wrote: Hi On Sun, 24 Feb 2008, Andrew Morton wrote: Hi Andrew, thanks a lot for reply, I'm attaching requested information. please let me know if You need more information/testing, whatever. I'll be glad to help. BR nik Areca support doesn't seem to be very interested in the problem :-( (cc's added) Please get the machine into this state of memory exhaustion then take copies of the output of the following, and send them via reply-to-all to this email: - cat /proc/meminfo - cat /proc/slabinfo - dmesg -c /dev/null ; echo m /proc/sysrq-trigger ; dmesg -c Thanks. Alas, that all looks OK to me. You never get any out-of-memory messages, and no oom-killing messages? Possibly what is happening here is that in this low-memory condition, some of the driver's internal memory-allocation attempts are failing, and the driver isn't correctly handling this. This is a rare situation which may well not have been hit in anyone else's testing. I expect that the Areca engineers will be able to reproduce this with a suitably small mem= kernel boot option. If not, they could perhaps investigate the kernel's fault-injection framework, which permits simulation of page allocation failures. -- 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 read the FAQ at http://www.tux.org/lkml/ -- - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Revert IB/fmr_pool: ib_fmr_pool_flush() should flush all dirty FMRs
On Tue, Feb 26, 2008 at 11:23:01AM -0800, Benny Halevy wrote: Pete, the subject says PATCH 1/2 but I didn't see any follow-up message for PATCH 2/2. Just wondering :) I think the problem's on your end ... I got it and so did marc: http://marc.info/?l=linux-scsim=120405067313933w=2 -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Revert IB/fmr_pool: ib_fmr_pool_flush() should flush all dirty FMRs
Diabolical ;-) Thanks for the pointer! Benny On Feb. 26, 2008, 11:39 -0800, Matthew Wilcox [EMAIL PROTECTED] wrote: On Tue, Feb 26, 2008 at 11:23:01AM -0800, Benny Halevy wrote: Pete, the subject says PATCH 1/2 but I didn't see any follow-up message for PATCH 2/2. Just wondering :) I think the problem's on your end ... I got it and so did marc: http://marc.info/?l=linux-scsim=120405067313933w=2 - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ofa-general] [PATCH 2/2] ib fmr pool: flush used clean entries
This looks like a really nice approach to me. Olaf? - R. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
