Re: [Question] vmalloc latency in RT-Linux

[Baoquan He <bhe@redhat.com>]

On 06/21/22 at 08:15pm, Zhipeng Shi wrote:
> I noticed in rt-linux, vmalloc has a large latency. This is because the 
> free_vmap_area_lock is held for a long time in the function  
> __purge_vmap_area_lazy. 
> 
> In non-RT-Linux, because the function spin_is_contended is well 
> implemented, so there will be no such problem.
> 
> But in RT-Linux, spin_is_contended simply returns 0. I don't understand 
> why this function was implemented like this before, but in order to
> solve this problem, I thought of two ways.
> 
> The first is to modify the spin_is_contended definition in spinlock_rt.h 
> as shown below, but I'm not sure if the change has side-effects:
> 
> -#define spin_is_contended(lock)    (((void)(lock), 0))
> +static inline int spin_is_contended(spinlock_t *lock)
> +{
> + unsigned long *p = (unsigned long *) &lock->lock.owner;
> +
> + return (READ_ONCE(*p) & RT_MUTEX_HAS_WAITERS);
> +}
> 
> The second is by reducing the number of lazy_max_pages, but it will lead 
> to lower performance of vmalloc.

__purge_vmap_area_lazy() has cond_resched_lock() to reschedule and drop
the lock. From your saying, it's spin_is_contended() which is not
working well to make rescheduling happen during __purge_vmap_area_lazy()
handling. Then the fixing should be done in lock side.

> 
> Guys, Do you have any good ideas?
> 
> Best regards,
> Zhipeng
>