[Top] [All Lists]

Re: Questions about pagebuf code

To: Nathan Scott <nathans@xxxxxxx>, linux-xfs@xxxxxxxxxxx
Subject: Re: Questions about pagebuf code
From: Craig Tierney <ctierney@xxxxxxxx>
Date: Mon, 03 May 2004 11:08:52 -0600
In-reply-to: <20040503162415.F124474@xxxxxxxxxxxxxxxxxxxxxxxx>
References: <1083435856.2302.3.camel@xxxxxxxxxxxxxxxxxxxxx> <20040501194709.A23768@xxxxxxxxxxxxx> <20040503162415.F124474@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
On Mon, 2004-05-03 at 00:24, Nathan Scott wrote:
> On Sat, May 01, 2004 at 07:47:09PM +0100, Christoph Hellwig wrote:
> > 
> > > 4) Would there be any reason (except performance) not to change
> > >    MAX_SLAB_SIZE to a smaller values (like 0), to test the behavior
> Oh, missed this - setting MAX_SLAB_SIZE to 0 will make all
> allocations go the vmalloc route... under no circumstances
> is that what you want to do.

Right.  That isn't what I meant.  I wanted to set MAX_SLAB_SIZE
to something to ensoure only kmalloc is ever used, not vmalloc.

> > >    when only kmalloc is used to allocation memory?
> > 
> > vmalloc can't be done from inside a spinlock.  Now that you mention
> > it I think we should explicitly check for that in the kmem_alloc code
> > instead of relying KM_NOSLEEP requests beeing small enough all the time..
> By adding {BUG/WARN}_ON checks on irqs_disabled() in kmem.h?
> (is there a 2.4 equivalent interface for that)?

I didn't see and references to irqs_disabled() in either
2.6.5 or 2.4.26.  Both 2.4.26 and 2.6.5 seem to have similar
references to and irq fuctions (spin_{un}lock_irqsave) in
debug.c and ktrace.c.   However in xfs_buf.c in 2.4.26, 
irq functions are called but not in 2.6.5.  Not sure if this
is significant.


> cheers.

<Prev in Thread] Current Thread [Next in Thread>