[Top] [All Lists]

Re: review: increase bulkstat readahead window

To: Nathan Scott <nathans@xxxxxxx>
Subject: Re: review: increase bulkstat readahead window
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Wed, 26 Jul 2006 11:25:51 +0100
Cc: cw@xxxxxxxx, vapo@xxxxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
In-reply-to: <20060726083709.B2118045@xxxxxxxxxxxxxxxxxxxxxxxx>
References: <20060725135004.E2116482@xxxxxxxxxxxxxxxxxxxxxxxx> <20060725094004.GB29615@xxxxxxxxxxxxx> <20060726083709.B2118045@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/
On Wed, Jul 26, 2006 at 08:37:09AM +1000, Nathan Scott wrote:
> On Tue, Jul 25, 2006 at 10:40:04AM +0100, Christoph Hellwig wrote:
> > On Tue, Jul 25, 2006 at 01:50:04PM +1000, Nathan Scott wrote:
> > > .. it up front.  We don't want to get silly in sizing this buffer, 
> > > though, as it needs to be a contiguous chunk of memory.  Here I've
> > > increased it from 1 page to 4 pages, with some logic to halve the
> > > size incrementally if we cant allocate that successfully (as we do
> > > in one or two other places in XFS, for other things).
> > 
> > ok.  I wonder whether we should add a generic kmalloc_leastmost routine
> > (with a name better than that of course..)
> Yeah, Chris suggested the same thing - probably we should, since two
> people suggested it now. :)  The XFS users I know of are the inode
> hash, the dquot hash, and this bulkstat code.  Oh, and probably the
> attr_multi ioctl code should use this for its buffer too.  If you can
> suggest a good interface, I'll have at it.

Maybe we can start with a common XFS routine first:

kmem_alloc_greedy(size_t *size, size_t minsize, unsigned int flags)
        void *ptr;

        while (!(ptr = kmem_alloc(*size, flags))) {
                if ((*size >>= 1) <= minsize)
                        flags = KM_SLEEP;

        return ptr;

> Semi-related, I have another patch which instruments our local memory
> allocation routines to add a KM_LARGE flag - I've been using this to
> locate and annotate the few remaining places where we will do multi-
> page allocations inside XFS... any interest in this patch?  I've been
> tossing up whether or not to merge it (its debug only, so no runtime
> 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.

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