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@xxxxxxxxx
:wq
|