History log of /dpdk/lib/eal/linux/eal_memalloc.c (Results 1 – 6 of 6)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v22.03, v22.03-rc4, v22.03-rc3, v22.03-rc2
# 30a1de10 15-Feb-2022 Sean Morrissey <[email protected]>

lib: remove unneeded header includes

These header includes have been flagged by the iwyu_tool
and removed.

Signed-off-by: Sean Morrissey <[email protected]>


Revision tags: v22.03-rc1
# 32b4771c 03-Feb-2022 Dmitry Kozlyuk <[email protected]>

eal/linux: allow hugepage file reuse

Linux EAL ensured that mapped hugepages are clean
by always mapping from newly created files:
existing hugepage backing files were always removed.
In this case,

eal/linux: allow hugepage file reuse

Linux EAL ensured that mapped hugepages are clean
by always mapping from newly created files:
existing hugepage backing files were always removed.
In this case, the kernel clears the page to prevent data leaks,
because the mapped memory may contain leftover data
from the previous process that was using this memory.
Clearing takes the bulk of the time spent in mmap(2),
increasing EAL initialization time.

Introduce a mode to keep existing files and reuse them
in order to speed up initial memory allocation in EAL.
Hugepages mapped from such files may contain data
left by the previous process that used this memory,
so RTE_MEMSEG_FLAG_DIRTY is set for their segments.
If multiple hugepages are mapped from the same file:
1. When fallocate(2) is used, all memory mapped from this file
is considered dirty, because it is unknown
which parts of the file are holes.
2. When ftruncate(3) is used, memory mapped from this file
is considered dirty unless the file is extended
to create a new mapping, which implies clean memory.

Signed-off-by: Dmitry Kozlyuk <[email protected]>
Reviewed-by: Anatoly Burakov <[email protected]>

show more ...


# 52d7d91e 03-Feb-2022 Dmitry Kozlyuk <[email protected]>

eal: refactor --huge-unlink storage

In preparation to extend --huge-unlink option semantics
refactor how it is stored in the internal configuration.
It makes future changes more isolated.

Signed-of

eal: refactor --huge-unlink storage

In preparation to extend --huge-unlink option semantics
refactor how it is stored in the internal configuration.
It makes future changes more isolated.

Signed-off-by: Dmitry Kozlyuk <[email protected]>
Acked-by: Thomas Monjalon <[email protected]>
Acked-by: Anatoly Burakov <[email protected]>

show more ...


# 8a5a9140 23-Dec-2021 Stephen Hemminger <[email protected]>

eal/linux: log hugepage create errors with filename

While debugging running DPDK service in a container, it is
useful to see which file creation failed. Don't hide this
failure with DEBUG.

Cc: sta

eal/linux: log hugepage create errors with filename

While debugging running DPDK service in a container, it is
useful to see which file creation failed. Don't hide this
failure with DEBUG.

Cc: [email protected]

Signed-off-by: Stephen Hemminger <[email protected]>
Acked-by: Bruce Richardson <[email protected]>

show more ...


Revision tags: v21.11, v21.11-rc4, v21.11-rc3, v21.11-rc2
# 9bffc928 29-Oct-2021 Olivier Matz <[email protected]>

mem: fix dynamic hugepage mapping in container

Since its introduction in 2018, the SIGBUS handler was never registered,
and all related functions were unused.

A SIGBUS can be received by the applic

mem: fix dynamic hugepage mapping in container

Since its introduction in 2018, the SIGBUS handler was never registered,
and all related functions were unused.

A SIGBUS can be received by the application when accessing to hugepages
even if mmap() was successful, This happens especially when running
inside containers when there is not enough hugepages. In this case, we
need to recover. A similar scheme can be found in eal_memory.c.

Fixes: 582bed1e1d1d ("mem: support mapping hugepages at runtime")
Cc: [email protected]

Signed-off-by: Olivier Matz <[email protected]>
Reviewed-by: Maxime Coquelin <[email protected]>
Acked-by: David Marchand <[email protected]>

show more ...


Revision tags: v21.11-rc1, v21.08, v21.08-rc4, v21.08-rc3, v21.08-rc2, v21.08-rc1, v21.05, v21.05-rc4, v21.05-rc3, v21.05-rc2, v21.05-rc1
# 99a2dd95 20-Apr-2021 Bruce Richardson <[email protected]>

lib: remove librte_ prefix from directory names

There is no reason for the DPDK libraries to all have 'librte_' prefix on
the directory names. This prefix makes the directory names longer and also
m

lib: remove librte_ prefix from directory names

There is no reason for the DPDK libraries to all have 'librte_' prefix on
the directory names. This prefix makes the directory names longer and also
makes it awkward to add features referring to individual libraries in the
build - should the lib names be specified with or without the prefix.
Therefore, we can just remove the library prefix and use the library's
unique name as the directory name, i.e. 'eal' rather than 'librte_eal'

Signed-off-by: Bruce Richardson <[email protected]>

show more ...