From: "Martin J. Bligh" <mbligh@aracnet.com>
To: "Luck, Tony" <tony.luck@intel.com>, lse-tech@lists.sourceforge.net
Cc: "Kamble, Nitin A" <nitin.a.kamble@intel.com>,
linux-kernel@vger.kernel.org, tomlins@cam.org, akpm@digeo.com
Subject: RE: [Lse-tech] [RFC] numa slab for 2.5.41-mm1
Date: Tue, 08 Oct 2002 16:34:09 -0700 [thread overview]
Message-ID: <599040000.1034120049@flay> (raw)
In-Reply-To: <39B5C4829263D411AA93009027AE9EBB1EF28EFB@fmsmsx35.fm.intel.com>
>> - is it possible implement ptr_to_nodeid()
>> on all archs efficiently? It will happen for every kfree().
>
> The best platform independent way that I came up with was to stash
> the node id in the page structure ... the initial patch that Nitin
> posted included code for this (and it's all my fault that this
> added an extra element to the page structure). I think that you
> suggested that slab could overload the use of some existing field
> if we wanted to pursue this direction.
>
> If ptr_to_nodeid() is made a platform dependent function, then
I think that's really the key .... the platforms should just make this
efficient, it's not something for the slab to worry about specifically.
Those of us that have virtual address space to burn can stick it in
struct page, whereas other people (eg me) might have to find some
other way to do it .... but that's the arch people's problem ;-)
> there are some platforms that can do this very efficiently (since
> the nodeid is embedded in some of the high-order address bits), and
> some for which this is complex (e.g. platforms that concatenate
> memory from each node).
M.
next prev parent reply other threads:[~2002-10-08 23:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-08 23:29 [Lse-tech] [RFC] numa slab for 2.5.41-mm1 Luck, Tony
2002-10-08 23:34 ` Martin J. Bligh [this message]
2002-10-09 0:50 ` David S. Miller
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=599040000.1034120049@flay \
--to=mbligh@aracnet.com \
--cc=akpm@digeo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
--cc=nitin.a.kamble@intel.com \
--cc=tomlins@cam.org \
--cc=tony.luck@intel.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 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.