This is not necessary on our systems and according to the documentation
will reduce code size of the allocator which will result in better
performance.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Acked-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
This is a new type of metric to find out what resource is currently a
bottleneck for the whole system. We might use this for graphs.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Acked-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
This change is required to make the system respond faster to any
realtime events (sending or receiving data packets).
It will wake up at least one core 1000 times a second which will result
in finer timer granularity and make scheduling smoother. HTB for
example sends large packet bursts on each timer even to keep up data
rates which is not helpful for most applications.
The change might increase resource consumption and overhead slightly on
some systems, but since we are running in an idle-dyntick configuration,
we should not keep awake any cores that have not been awake before.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Acked-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
this is needed for newer USB enclosures to support trim
and get better speed. (already enabled on x86*)
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
This will increase throughput since BBR is more modern and adjusted to
the nowadays version of the Internet whereas Cubic is more conservative
and might not always fully saturate the downlink.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
ACPI (with EFI) is used on ARM systems conforming to the
Server Base Boot Requirements (SBBR) and is an optional
on embedded systems (EBBR).
Up to now the ARM64 boards supported by IPFire use U-Boot and
device tree so ACPI was not turned on.
The immediate use case here is to run under virtualization,
using my muvirt project[1] I can run IPFire on our Traverse Ten64
system. For reasons I'll explain separately it is not
currently possible to run stock IPFire on this system.
This change also enables the EFI RTC driver which is presented
by the qemu arm64 virt machine.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
[1] - https://gitlab.com/traversetech/muvirt
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
Quoted from #12433:
> Uprobes is the user-space counterpart to kprobes: they enable instrumentation
> applications (such as 'perf probe') to establish unintrusive probes in
> user-space binaries and libraries, by executing handler functions when the
> probes are hit by user-space applications.
>
> ( These probes come in the form of single-byte breakpoints, managed by the
> kernel and kept transparent to the probed application. )
IMHO this can be safely disabled, as there is little if any need to debug
userspace programs _that_ deeply on an IPFire machine.
Fixes: #12433
Cc: Arne Fitzenreiter <arne.fitzenreiter@ipfire.org>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
