From: Nathan Scott <nathans@sgi.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: cw@f00f.org, vapo@melbourne.sgi.com, xfs@oss.sgi.com
Subject: Re: review: increase bulkstat readahead window
Date: Fri, 28 Jul 2006 09:17:35 +1000 [thread overview]
Message-ID: <20060728091735.B2196410@wobbly.melbourne.sgi.com> (raw)
In-Reply-To: <20060726102551.GA9141@infradead.org>; from hch@infradead.org on Wed, Jul 26, 2006 at 11:25:51AM +0100
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
next prev parent reply other threads:[~2006-07-27 23:19 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-25 3:50 review: increase bulkstat readahead window Nathan Scott
2006-07-25 9:40 ` Christoph Hellwig
2006-07-25 22:37 ` Nathan Scott
2006-07-26 10:25 ` Christoph Hellwig
2006-07-27 23:17 ` Nathan Scott [this message]
2006-07-28 1:58 ` Review: xfs_repair fixes for dir2 corruption Barry Naujok
2006-07-28 8:10 ` Nathan Scott
2006-07-28 14:45 ` Madan Valluri
2006-07-31 7:18 ` Barry Naujok
2006-07-30 5:19 ` christian
2006-08-01 21:50 ` Adam Sjøgren
2006-08-01 23:06 ` Christian Guggenberger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060728091735.B2196410@wobbly.melbourne.sgi.com \
--to=nathans@sgi.com \
--cc=cw@f00f.org \
--cc=hch@infradead.org \
--cc=vapo@melbourne.sgi.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox