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.
|