Date: Fri, 19 Jan 2001 16:19:56 +0100 From: Xavier Galleri <xgalleri@enition.com> To: freebsd-hackers@FreeBSD.ORG Subject: Kernel memory allocation bug ... Message-ID: <3A685B1C.2010302@enition.com> References: <20010116132456.W7240@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi everybody,
This mail is related to the 'Need help for crash dump analysis' mail
serie and the more recent 'Information on kernel crash dump analysis' mail.
I have achieved to (manually) get a stack dump by getting my 'curpcb'
value at the time I call MALLOC and then issuing 'info frame' and
'frame' commands when analyzing the dump (I will post some explanations
on the process in the 'hackers' mailing list). Here is the result of
this analysis (frame numbering is of my own, for clearness):
#0 mi_switch () at ../../kern/kern_synch.c:858
858 if (switchtime.tv_sec == 0)
#1 tsleep (ident=0xc08c5bf0, priority=4, wmesg=0xc0330531 "vmopar",
timo=0) at ../../kern/kern_synch.c:469
469 curpriority = p->p_usrpri;
#2 vm_object_page_remove (object=0xc0388940, start=4344, end=4352,
clean_only=0) at ../../vm/vm_page.h:547
547 }
#3 vm_map_delete (map=0xc03887e0, start=3237965824, end=3237998592) at
../../vm/vm_map.c:1810
1810 } else {
#4 kmem_malloc (map=0xc03887e0, size=32768, flags=1) at
../../vm/vm_kern.c:366
366 vm_map_unlock(map);
#5 0xc018df07 in malloc (size=32768, type=0xc035b2e0, flags=1) at
../../kern/kern_malloc.c:188
188 va = (caddr_t) kmem_malloc(kmem_map,
(vm_size_t)ctob(npg), flags);
#6 0xc02a9a8f in init_CGW () at ../nettoll/toll_token.c:260
260 ../nettoll/toll_token.c: No such file or directory.
The last frame is where I actually call MALLOC. This macro leads to
actually call 'malloc' which means a bucket shortage (size is 32Kb).
Then, we come to the 'kmem_alloc' call. First, this is done with
flags==M_NOWAIT, thus discarding any (usage) error from this side. Frame
#3 is (I guess ;-) coming from that 'vm_map_unlock' is a macro and it
should point to the line above in the code (vm_kern.c:365) where
'vm_map_delete' is actually called. This is enclosed in a conditional
code portion that is a consequence of a failure of the 'vm_page_alloc'
call, meaning that "we ran out of space" (cf. comment in code). That is
bad news for me and I will take a look at what's going on around this
problem. That said, frames #2 and #1 show that the caller is actually
falling asleep (under non-trivial circumstances, but this remains a fact
!), while the higher call to malloc specified M_NOWAIT and my guess is
that this sounds like a ... bug !
Now, I come back to the memory shortage aspect of this problem. I have
displayed some fields of the 'struct vmmeter cnt' data and found that a
the 'free' count of pages has fallen almost to zero at some point (which
explains the failure of 'vm_page_alloc') and that, on the other side,
the 'inactive' count has jumped to a very hight level (to a total of
around 90-100 Mb). I have almost asserted that this jump was due to a
big tar command that is part of my test conditions. Then are my questions :
* As far as I can see, the 'inactive' pages are those that are neither
in the cache list nor in the free list, thus being currently unused, but
still usable by the I/O subsystem (mostly for buffer cache).
Consequently, these pages cannot be reused directly as VM resources
since they could be dirty and required back writing to disk. Is that
correct ?
* In good case (cf. above), any heavy VFS activity could quickly imply a
shortage of the 'free' page list, that could lead to the misbehaviour of
'malloc' as explained above. This means that VFS (through buffer cache)
and VM are competing for memory in such a way that VM seems to have less
priority than VFS. Is that correct ?
* Are there any recent upgrades in the FreeBSD VM management that could
help me cope with my problem ?
Finally, I would greatly appreciate to have an expert advise for my
problem, especially on its actual buggy status.
Regards,
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A685B1C.2010302>