5:32 p.m.
Hi All,
1) DPDK fails if huge-pages are not reserved. But should not it fall
back to regular 4k pages ?
2) And how user space should know the requirement of number of hug
pages before-hand ?
a. Rather should it always be reserved before-hand in the system?,
with that we might waste some.
root@bcm958742t:~# /usr/share/spdk/examples/nvme/perf -r 'trtype:PCIe
traddr:0000:01:00.0' -q 128 -s 4096 -w write -d 2048 -t 30 -c 0x1
Starting DPDK 16.11.1 initialization...
[ DPDK EAL parameters: perf -c 1 -m 2048 --file-prefix=spdk_pid3[
187.734815] audit: type=1701 audit(1500448013.777:3): auid=4294967295 uid=0
gid=0 ses=4294967295 pid=3465 comm="perf"
exe="/usr/share/spdk/examples/nvme/perf" sig=6 res=1
465 ]
EAL: Detected 8 lcore(s)
EAL: No free hugepages reported in hugepages-2048kB
PANIC in rte_eal_init():
Cannot get hugepage information
1: [/usr/share/spdk/examples/nvme/perf() [0x4197d4]]
Aborted (core dumped)
Regards,
Oza.
7:12 a.m.
On Wed, 2017-07-19 at 14:02 +0530, Oza Oza wrote:
Hi All,
1) DPDK fails if huge-pages are not reserved. But should not it fall back
to regular 4k pages ?
Hugepages are not just used for efficiency reasons - they're used as a way to
get DMA safe memory in user space. I wrote an extensive overview of the
challenges in this area here:
http://www.spdk.io/doc/memory.html
2) And how user space should know the requirement of number of
hug pages
before-hand ?
a. Rather should it always be reserved before-hand in the system?, with
that we might waste some.
I agree that this is a real usability challenge and a more dynamic memory
allocator for hugepages would be a great leap forward for both DPDK and SPDK.
Until we get to that point, you have to pre-reserve pages and you'll probably
waste some amount of memory.
Regards,
Oza.
_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org
https://lists.01.org/mailman/listinfo/spdk
1328
days inactive
1328
days old
1 comments
2 participants
participants (2)
-
Oza Oza -
Walker, Benjamin