Skip to content

fs/buffer.c: disable per-CPU buffer_head cache for isolated CPUs

commit 8a237adf213d73671992266eff7437f1b9f40567 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2158709 Testing: tested by verifying the function call IPI is not initiated to isolated CPUs

For certain types of applications (for example PLC software or RAN processing), upon occurrence of an event, it is necessary to complete a certain task in a maximum amount of time (deadline).

One way to express this requirement is with a pair of numbers, deadline time and execution time, where:

    * deadline time: length of time between event and deadline.
    * execution time: length of time it takes for processing of event
                      to occur on a particular hardware platform
                      (uninterrupted).

The particular values depend on use-case. For the case where the realtime application executes in a virtualized guest, an IPI which must be serviced in the host will cause the following sequence of events:

    1) VM-exit
    2) execution of IPI (and function call)
    3) VM-entry

Which causes an excess of 50us latency as observed by cyclictest (this violates the latency requirement of vRAN application with 1ms TTI, for example).

invalidate_bh_lrus calls an IPI on each CPU that has non empty per-CPU cache:

    on_each_cpu_cond(has_bh_in_lru, invalidate_bh_lru, NULL, 1);

The performance when using the per-CPU LRU cache is as follows:

42 ns per __find_get_block 68 ns per __find_get_block_slow

Given that the main use cases for latency sensitive applications do not involve block I/O (data necessary for program operation is locked in RAM), disable per-CPU buffer_head caches for isolated CPUs.

Signed-off-by: Marcelo Tosatti mtosatti@redhat.com Acked-by: Frederic Weisbecker frederic@kernel.org Message-Id: ZJtBrybavtb1x45V@tpad Signed-off-by: Christian Brauner brauner@kernel.org

Merge request reports