Bug 183555 - bio and biovec-1 total slab sizes grow until machine is unusable
Summary: bio and biovec-1 total slab sizes grow until machine is unusable
Keywords:
Status: CLOSED DUPLICATE of bug 182970
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-03-01 21:51 UTC by Alexandre Oliva
Modified: 2015-01-04 22:25 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-03-02 04:16:06 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Alexandre Oliva 2006-03-01 21:51:45 UTC
Description of problem:
My Athlon64X2 desktop has 2GB of RAM.  Rebooting the box every day into a newer
rawhide kernel, it's quite usable, but if I miss a reboot, using it on the next
day is intolerable.  slabtop shows the bio and biovec-1 total sizes grow taking
up most of the available RAM:

6796500 6794136  99%    0.04K  73875       92    295500K biovec-1

6796440 6794138  99%    0.12K 226548       30    906192K bio

 09:48:58 up 17:05, 12 users,  load average: 1.82, 1.72, 1.93

Mem:   2055876k total,  2033228k used,    22648k free,     5400k buffers
Swap:  4194288k total,   155296k used,  4038992k free,   249476k cached

A few hours later, when I finally rebooted the box, bio had grown to 990K and
biovec-1 was reaching 350K.  This was with kernel-2.6.15-1.1991_FC5.x86_64. 
With today's kernel, 1996, the problem does not appear to be fixed.  bio and
biovec-1 were much smaller right after I booted up (100k entries each), but now,
just 2 hours later, they're already at the top of slabtop:

252080 251972  99%    0.04K   2740       92     10960K biovec-1
252030 251977  99%    0.12K   8401       30     33604K bio

On nearly-identical boxes running FC4 at the uni, bio and biovec-1 don't even
show up on slabtop, neither on the disk servers (that only differ in the number
of local disks) nor on the desktop box, so all use patterns are covered.

On the previous session, I'd plugged in my external disk connected over
firewire.  This time, pondering that might be it, I didn't even do that, but it
keeps growing anyway.  It's probably not it anyway, because my x86_64 notebook
has a firewire disk permanently connected to it, mirroring the internal disk,
and bio and biovec-1 are not on the map there.  It also uses RAID in pretty much
the same way.

Oh, another difference in software configuration is that I use the VESA driver
for X on this box, whereas the boxes at the uni use radeon.  Could this possibly
cause bio and biovec-1 slabs to grow like that?  With the nv driver, on the
other notebook, no such effect occurs.

Version-Release number of selected component (if applicable):
kernel-2.6.15-1.1996_FC5.x86_64

How reproducible:
Every time

Steps to Reproduce:
1.Boot the box up
2.Use it normally
  
Actual results:
Next day, it's unusable.  Disk caches shrink and need for swap sky rockets as
slab space devoted to bio and biovec-1 takes up all memory.

Expected results:
No such memory leak

Additional info:

Comment 1 Dave Jones 2006-03-02 04:16:06 UTC

*** This bug has been marked as a duplicate of 182970 ***


Note You need to log in before you can comment on or make changes to this bug.