xfs
[Top] [All Lists]

Re: review: increase bulkstat readahead window

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: review: increase bulkstat readahead window
From: Nathan Scott <nathans@xxxxxxx>
Date: Fri, 28 Jul 2006 09:17:35 +1000
Cc: cw@xxxxxxxx, vapo@xxxxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
In-reply-to: <20060726102551.GA9141@xxxxxxxxxxxxx>; from hch@xxxxxxxxxxxxx on Wed, Jul 26, 2006 at 11:25:51AM +0100
References: <20060725135004.E2116482@xxxxxxxxxxxxxxxxxxxxxxxx> <20060725094004.GB29615@xxxxxxxxxxxxx> <20060726083709.B2118045@xxxxxxxxxxxxxxxxxxxxxxxx> <20060726102551.GA9141@xxxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.2.5i
On Wed, Jul 26, 2006 at 11:25:51AM +0100, Christoph Hellwig wrote:
> Maybe we can start with a common XFS routine first:
> 
> kmem_alloc_greedy(size_t *size, size_t minsize, unsigned int flags)

Looks good, I'll create a patch & send out later today.  Actually,
we could say minsize is 1 page, and simplify - for our uses in XFS,
that will suffice... or dya want that extra parameter for the more
generic version later?

> > cost is added for usual case), just so we can always easily see where
> > the large allocations are, and trap any inadvertantly introduced new
> > ones... thoughts?
> 
> I'm happy with that flag, but I'd prefer it only allocations with
> KM_LARGE would go to vmalloc so that we can start to untangle the
> allocator wrapping mess.

Yep - that was the other reason why I started down that path - I'm not
convinced we really need the vmalloc calls anymore, we don't get near
the max slab cutoff on my i386 test box anyway, AFAICT.  Long term, we
should be removing the vmalloc call, but needs more beating to be sure
nothing can get there nowadays - ultimately we should just BUG_ON over
a max size (below the current vmalloc cutoff).

cheers.

-- 
Nathan


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