From: Keith Owens <kaos@ocs.com.au>
To: linux-ia64@vger.kernel.org
Subject: [Linux-ia64] [RFC] NUMA functions for accessing replicated areas
Date: Sat, 19 Jan 2002 00:25:17 +0000 [thread overview]
Message-ID: <marc-linux-ia64-105590698805884@msgid-missing> (raw)
The linux kernel debugger (kdb) has hit a problem with setting software
breakpoints on NUMA boxes with replicated kernel text. Instead of
changing one kernel virtual address and affecting the only copy of the
kernel, kdb has to loop over each replicated area and change each copy
of the kernel individually, using some mapping that gives access to the
data on other nodes.
I don't want code in kdb that knows about every NUMA platform, that is
a maintenance nightmare. I want the NUMA platforms to provide the
following interfaces. Any objections or changes? I will do the the
SGI version, other manufacturers will have to provide the equivalent
functions if they want to use kdb.
BTW, is there a single NUMA mailing list? cc: me please, I am not on
all lists.
CONFIG_NUMA_REPLICATE
Set to y if the platform supports the replication functions.
int numa_replicated(unsigned long address, size)
Return 0 if the area (address to address+size-1) is not replicated.
Return 1 if it is replicated.
Return -EINVAL if the area is a mixture of replicated and
non-replicated data.
int numa_replicate_loop(unsigned long address, (int *func)(void *numadata, void *funcdata), void *funcdata)
Call the function for each replication of the address. numadata
identifies this instance of the replicated data, it is an opaque
cookie to the function. funcdata is supplied by the caller of
numa_replicate_loop(), it is an opaque cookie to the numa code.
Return 0 if the function returns 0 for all calls, otherwise 1. If
any call to func() returns non-zero, numa_replicate_loop() continues
with the other replicated areas. If func() wants to ignore
subsequent areas it can set a flag in funcdata.
int numa_replicate_getarea_size(void *to, unsigned long from_xxx, size_t size, void *numadata)
Read size bytes from from_xxx (which must be a replicated address) to
the user's data area.
Return 0 on success, -EFAULT for invalid from_xxx address or size.
int numa_replicate_putarea_size(unsigned long to_xxx, void *from, size_t size, void *numadata)
Write size bytes from the user's data area to to_xxx (which must be a
replicated address).
Return 0 on success, -EFAULT for invalid to_xxx address or size.
Is that satisfactory? Once those routines exist, kdb can use them to
set software breakpoints.
reply other threads:[~2002-01-19 0:25 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=marc-linux-ia64-105590698805884@msgid-missing \
--to=kaos@ocs.com.au \
--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