From: Bart Van Assche <bvanassche@acm.org>
To: Jeff Moyer <jmoyer@redhat.com>
Cc: axboe@kernel.dk, linux-kernel@vger.kernel.org,
SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [patch/rfc/rft] sd: allocate request_queue on device's local numa node
Date: Tue, 23 Oct 2012 19:42:03 +0200 [thread overview]
Message-ID: <5086D6EB.7020701@acm.org> (raw)
In-Reply-To: <x49fw556sgu.fsf@segfault.boston.devel.redhat.com>
On 10/23/12 18:52, Jeff Moyer wrote:
> Bart Van Assche <bvanassche@acm.org> writes:
>> Please keep in mind that a
>> single PCIe bus may have a minimal distance to more than one NUMA
>> node. See e.g. the diagram at the top of page 8 in
>> http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c03261871/c03261871.pdf
>> for a system diagram of a NUMA system where each PCIe bus has a
>> minimal distance to two different NUMA nodes.
>
> That's an interesting configuration. I wonder what the numa_node sysfs
> file contains for such systems--do you know? I'm not sure how we could
> allow this to be user-controlled at probe time. Did you have a specific
> mechanism in mind? Module parameters? Something else?
As far as I can see in drivers/pci/pci-sysfs.c the numa_node sysfs
attribute contains a single number, even for a topology like the one
described above.
With regard to user control of the numa node: I'm not sure how to solve
this in general. But for the ib_srp driver this should be easy to do:
SCSI host creation is triggered by sending a login string to a sysfs
attribute ("add_target"). It wouldn't take much time to add a parameter
to that login string that specifies the NUMA node.
Bart.
next prev parent reply other threads:[~2012-10-23 17:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-22 19:01 [patch/rfc/rft] sd: allocate request_queue on device's local numa node Jeff Moyer
2012-10-22 19:19 ` Jens Axboe
2012-10-23 6:45 ` Bart Van Assche
2012-10-23 16:52 ` Jeff Moyer
2012-10-23 17:42 ` Bart Van Assche [this message]
2012-10-23 17:58 ` Jens Axboe
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=5086D6EB.7020701@acm.org \
--to=bvanassche@acm.org \
--cc=axboe@kernel.dk \
--cc=jmoyer@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@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.