From: Robin Holt <holt@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [rfc] generic allocator and mspec driver
Date: Thu, 03 Feb 2005 11:19:44 +0000 [thread overview]
Message-ID: <20050203111944.GA22664@lnx-holt.americas.sgi.com> (raw)
In-Reply-To: <16897.9640.160896.31584@jaguar.mkp.net>
> Jack> Ugly hack. Isn't there a better way? (I know this isn't your
> Jack> code & you probably don't like this either. I had hoped for a
> Jack> cleaner solution in 2.6....)
>
> It's gross, ugly and I hate it ... not sure if there's a simpler way.
> Maybe we can use the same approach as the fbmem driver and do it all
> in the mmap() function, I will have to investigate that.
If you do it in the mmap, all the pages will be allocated and mapped
on the node doing the map. This will result in large applications
using multiple threads to incur _LARGE_ amounts of numa traffic.
The first fault is critical for performance.
>
> Jack> + /* + * Use the bte to ensure cache lines + * are actually
> Jack> pulled from the + * processor back to the md. + */ +
>
> Jack> This doesn't need to be done if the memory was being used for
> Jack> fetchops or uncached memory.
>
> I'll check.
The bte zero is needed for memory mapped cached (one of the mechanisms
here) and also ensures the memory is zereod out when returned to the
memory pool.
next prev parent reply other threads:[~2005-02-03 11:19 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-02 19:10 [rfc] generic allocator and mspec driver Jes Sorensen
2005-02-02 19:46 ` Jesse Barnes
2005-02-02 23:33 ` Jack Steiner
2005-02-03 7:47 ` Jes Sorensen
2005-02-03 8:38 ` Jes Sorensen
2005-02-03 11:19 ` Robin Holt [this message]
2005-02-03 14:55 ` Jes Sorensen
2005-02-03 17:06 ` Jesse Barnes
2005-02-03 17:31 ` Dean Roe
2005-02-03 17:31 ` Robin Holt
2005-02-03 17:41 ` Jesse Barnes
2005-02-03 18:54 ` Jack Steiner
2005-02-03 19:39 ` David Mosberger
2005-02-03 20:58 ` Jes Sorensen
2005-02-03 21:40 ` Luck, Tony
2005-02-04 1:00 ` David Mosberger
2005-02-13 21:57 ` Jes Sorensen
2005-02-14 19:12 ` Luck, Tony
2005-02-14 19:17 ` David Mosberger
2005-02-15 8:43 ` Jes Sorensen
2005-02-15 8:44 ` Jes Sorensen
2005-02-15 17:35 ` Grant Grundler
2005-02-15 18:04 ` David Mosberger
2005-02-15 18:05 ` David Mosberger
2005-02-15 19:11 ` Robin Holt
2005-02-15 19:19 ` David Mosberger
2005-02-15 19:49 ` Robin Holt
2005-02-15 19:59 ` Jes Sorensen
2005-02-15 20:02 ` Jes Sorensen
2005-02-15 20:24 ` Robin Holt
2005-02-16 7:32 ` Jes Sorensen
2005-02-16 14:17 ` Jes Sorensen
2005-02-16 17:50 ` Luck, Tony
2005-02-16 18:18 ` Luck, Tony
2005-02-16 19:10 ` Jes Sorensen
2005-02-16 21:02 ` David Mosberger
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=20050203111944.GA22664@lnx-holt.americas.sgi.com \
--to=holt@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox