Re: kmem_alloc() issues

[Steeve McCauley <smccauley@max-t.com>]

On Wed, Mar 20, 2002 at 12:54:31PM -0600, Steve Lord wrote:
> 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.

Ah yes.  It was there in 2.4.16 ...

> > 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().

Note that it's a lot better now with the 2.4.17
changes to shrink_cache; the way that max_mapped
is calculated.  This is a good suggestion though,
thanks.

On to 2.4.18 :)

-- 
Steeve McCauley                         Maximum Throughput
Programmer & Team Leader                smccauley@max-t.com
:wq