From: Jesse Barnes <jbarnes@engr.sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [PATCH] general config option cleanup
Date: Wed, 08 Sep 2004 22:10:08 +0000 [thread overview]
Message-ID: <200409081510.08823.jbarnes@engr.sgi.com> (raw)
In-Reply-To: <200409081447.38703.jbarnes@engr.sgi.com>
On Wednesday, September 8, 2004 3:03 pm, Matthew Wilcox wrote:
> On Wed, Sep 08, 2004 at 02:47:38PM -0700, Jesse Barnes wrote:
> > As threatened, here's a patch that unifies the ia64 memory init and
> > memmap codepaths by unconditionalizing the CONFIG_VIRTUAL_MEM_MAP code
> > and making CONFIG_DISCONTIGMEM required. It also allows building with
> > CONFIG_SMP=n and/or CONFIG_NUMA=n. The end result should be easier to
> > understand and hack on, and should make things like memory hotplug that
> > much easier since people will only have to worry about one code path
> > instead of every combination of the three options.
>
> I don't really like this. It penalises platforms like Intel's Tiger box
> that have contiguous memory. I'd really like to see VIRTUAL_MEM_MAP go
> away and the DISCONTIGMEM code be usable for both zx1/sx1000 and sn2.
Have you tried to measure the penalty for discontigmem? I have, and without
writing a kernel module that counts the number of alloc_pages calls one could
do in a tight loop, I don't think it's measurable. virtual memmap is a
little more expensive (i.e. it shows up on benchmarks as something slightly
more than noise), but isn't the simplification worth it? We've had
CONFIG_DISCONTIGMEM=y/n and/or CONFIG_VIRTUAL_MEM_MAP=y/n breakages several
times now...
Jesse
next prev parent reply other threads:[~2004-09-08 22:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-08 21:47 [PATCH] general config option cleanup Jesse Barnes
2004-09-08 22:03 ` Matthew Wilcox
2004-09-08 22:10 ` Jesse Barnes [this message]
2004-09-08 22:11 ` Luck, Tony
2004-09-09 1:02 ` Ian Wienand
2004-09-09 1:07 ` Jesse Barnes
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=200409081510.08823.jbarnes@engr.sgi.com \
--to=jbarnes@engr.sgi.com \
--cc=linux-ia64@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.