lkml.org 
[lkml]   [2021]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [RFC 09/26] mm, slub: move disabling/enabling irqs to ___slab_alloc()
    Date
    On 5/25/21 2:47 PM, Vlastimil Babka wrote:
    > On 5/25/21 2:35 PM, Mel Gorman wrote:
    >>
    >> Why did you use migrate_disable instead of preempt_disable? There is a
    >> fairly large comment in include/linux/preempt.h on why migrate_disable
    >> is undesirable so new users are likely to be put under the microscope
    >> once Thomas or Peter notice it.
    >
    > I understood it as while undesirable, there's nothing better for now.

    Ah I now recalled the more important reason. By my understanding of
    Documentation/locking/locktypes.rst it's not possible on PREEMPT_RT to do a
    preempt_disable() and then take a spin_lock (or local_lock) which is a mutex on
    RT and needs preemption enabled to take it. And one of the goals is that
    list_lock would not have to be raw_spinlock on RT anymore.

    >> I think you are using it so that an allocation request can be preempted by
    >> a higher priority task but given that the code was disabling interrupts,
    >> there was already some preemption latency.
    >
    > Yes, and the disabled interrupts will get progressively "smaller" in the series.
    >
    >> However, migrate_disable
    >> is more expensive than preempt_disable (function call versus a simple
    >> increment).
    >
    > That's true, I think perhaps it could be reimplemented so that on !PREEMPT_RT
    > and with no lockdep/preempt/whatnot debugging it could just translate to an
    > inline migrate_disable?

    Correction: I meant "translate to an inline preempt_disable" which would then
    not change anything for !PREEMPT_RT.

    \
     
     \ /
      Last update: 2021-05-25 19:25    [W:3.738 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site