diff options
| author | Anton Blanchard <anton@samba.org> | 2011-11-02 22:56:22 +0100 |
|---|---|---|
| committer | James Bottomley <JBottomley@Parallels.com> | 2011-11-03 08:19:50 +0100 |
| commit | f7c9c6bb14f3104608a3a83cadea10a6943d2804 (patch) | |
| tree | 15d0ddbe43a1053c95e247814daad279690e63ac /drivers/scsi/scsi_scan.c | |
| parent | [SCSI] scsi_dh_alua: Fix the time inteval for alua rtpg commands (diff) | |
| download | linux-f7c9c6bb14f3104608a3a83cadea10a6943d2804.tar.xz linux-f7c9c6bb14f3104608a3a83cadea10a6943d2804.zip | |
[SCSI] Fix block queue and elevator memory leak in scsi_alloc_sdev
When looking at memory consumption issues I noticed quite a
lot of memory in the kmalloc-2048 bucket:
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
6561 6471 98% 2.30K 243 27 15552K kmalloc-2048
Over 15MB. slub debug shows that cfq is responsible for almost
all of it:
# sort -nr /sys/kernel/slab/kmalloc-2048/alloc_calls
6402 .cfq_init_queue+0xec/0x460 age=43423/43564/43655 pid=1 cpus=4,11,13
In scsi_alloc_sdev we do scsi_alloc_queue but if slave_alloc
fails we don't free it with scsi_free_queue.
The patch below fixes the issue:
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
135 72 53% 2.30K 5 27 320K kmalloc-2048
# cat /sys/kernel/slab/kmalloc-2048/alloc_calls
3 .cfq_init_queue+0xec/0x460 age=3811/3876/3925 pid=1 cpus=4,11,13
Signed-off-by: Anton Blanchard <anton@samba.org>
Cc: <stable@kernel.org> #2.6.38+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Diffstat (limited to 'drivers/scsi/scsi_scan.c')
| -rw-r--r-- | drivers/scsi/scsi_scan.c | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c index 44e8ca398efa..72273a0e5666 100644 --- a/drivers/scsi/scsi_scan.c +++ b/drivers/scsi/scsi_scan.c @@ -322,6 +322,7 @@ out_device_destroy: scsi_device_set_state(sdev, SDEV_DEL); transport_destroy_device(&sdev->sdev_gendev); put_device(&sdev->sdev_dev); + scsi_free_queue(sdev->request_queue); put_device(&sdev->sdev_gendev); out: if (display_failure_msg) |