[<prev] [next>] [day] [month] [year] [list]
Message-ID: <9643105.1203728826946.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net>
Date: Fri, 22 Feb 2008 17:07:06 -0800 (GMT-08:00)
From: erblichs <erblichs@...thlink.net>
To: linux-kernel@...r.kernel.org
Cc: erblichs@...thlink.net
Subject: RFE: __alloc_pages() SLAB_PANIC & gfp_mask
Group,
Currrently I do not subscribe to this mail alias, so please
keep the cc.
Currently a few calls exist where WAIT is specified (
(GFP_KERNEL)for the slab/slob allocators and also as an
additional argument, SLAB_PANIC is checked against the
return of the request for memory allocation. SLAB_PANIC
is not passed to __alloc_pages() as part of the gfp_mask.
If the memory allocation fails, and the flag is turned
on, then a panic will ensure.. There is a very simple fix
for this. The assumption is too basicly ASSERT a guarantee
that memory failure in this case will not occur.
The suggestion is to add the SLAB_PANIC arg to the gfp_mask,
add it to the mask in the SLAB/SLUB callers,
and have that checked within __alloc_pages
if a mem alloc failure is about to occur
after the check for no WAITers.
If it is set, then force additional loops within the function.
This would remove new cache creates from causing a panic when
a low memory condition exists.
Mitchell Erblich
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists