On Fri, 2002-03-08 at 16:54, Mr. Fiddlehead wrote:
> file: fs/xfs_support/kmem.c
>
> When kmem_alloc() fails to get a kmalloc() within
> DEF_PRIORITY retries it will alloc the memory from
> __vmalloc() which will cause an Oops when the memory
> is kmem_free()'d if the size is <= MAX_SLAB_SIZE.
I think this will fix that problem:
*** 155,164 ****
void
kmem_free(void *ptr, size_t size)
{
! if (MAX_SLAB_SIZE < size){
! vfree(ptr);
! } else {
kfree(ptr);
}
}
--- 155,165 ----
void
kmem_free(void *ptr, size_t size)
{
! struct page *p = virt_to_page(ptr);
! if (VALID_PAGE(p) && PageSlab(p)) {
kfree(ptr);
+ } else {
+ vfree(ptr);
}
}
>
> Further, just before the panic, the line should read,
>
> if (!rval && (flags & KM_SLEEP))
> panic()
>
> but would that be more proper as,
>
> if (!rval && (flags & (KM_SLEEP | KM_SLEEP_IO))
> panic()
KM_SLEEP_IO is gone in recent kernels.
>
> Note that lowering MAX_SLAB_SIZE to 64K from 128K
> helps alleviate this problem, as well as putting in a
> retry instead of the panic(). On linux 2.4.16 I'm
> seeing this on a system with 512MB of RAM on an SMP
> system with 1.7TB of attached storage (LSI raid 5 via
> software raid 0). This helps to alleviate the
> pressure on the bigger slabs (size-64 and size-128).
> I tried lowering it to 32K but this bombed on boot
> when the aic7xxx was initialised.
I will try this here for a while.
>
> I've also inserted a
> wake_up_interruptible(&kswapd_wait) here before
> resetting shrink to 24 (instead of 6) and repeating.
> I've seen the system retry up to about 48 times, which
> is bad, but not as bad as a panic.
hmm, there might be better things to do than this, possibly
calling free_more_memory().
>
> This appears to be a problem with the page cache not
> releasing pages for use by the slab cache (kmalloc),
> since I still have about 450MB of inactive page cache
> available when this happens.
>
> This could also happen under VERY severe conditions in
> kmem_zone_alloc() and kmem_zone_zalloc() but it is
> very unlikely I suspect.
>
> Cheers!
>
> Mr F.
Thanks,
Steve
>
>
--
Steve Lord voice: +1-651-683-3511
Principal Engineer, Filesystem Software email: lord@xxxxxxx
|