Re: review: increase bulkstat readahead window

[Christoph Hellwig <hch@infradead.org>]

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.