Bug 183555 - bio and biovec-1 total slab sizes grow until machine is unusable
bio and biovec-1 total slab sizes grow until machine is unusable
Status: CLOSED DUPLICATE of bug 182970
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2006-03-01 16:51 EST by Alexandre Oliva
Modified: 2015-01-04 17:25 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-01 23:16:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2006-03-01 16:51:45 EST
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):

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-01 23:16:06 EST

*** 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.