Messages in this thread | | | From | Vlastimil Babka <> | Subject | Re: [RFC 09/26] mm, slub: move disabling/enabling irqs to ___slab_alloc() | Date | Tue, 25 May 2021 19:24:44 +0200 |
| |
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.
| |