Re: Excessive TLB flush ranges

[Thomas Gleixner <tglx@linutronix.de>]

On Fri, May 19 2023 at 19:49, Baoquan He wrote:
> On 05/19/23 at 01:22pm, Thomas Gleixner wrote:
>> >
>> > When vb_free() is invoked, it could cause three kinds of vmap_block as
>> > below. Your code works well for the 2nd case, for the 1st one, it may be
>> > not. And the 2nd one is the stuff that we reclaim and put into purge
>> > list in purge_fragmented_blocks_allcpus().
>> >
>> > 1)
>> >   |-----|------------|-----------|-------|
>> >   |dirty|still mapped|   dirty   | free  |
>> >
>> > 2)
>> >   |------------------------------|-------|
>> >   |         dirty                | free  |
>> 
>> 
>> You sure? The first one is put into the purge list too.
>
> No way. You don't copy the essential code here. The key line is
> calculation of vb->dirty. ->dirty_min and ->dirty_max only provides a
> loose vlaue for calculating the flush range. Counting more or less page
> of ->dirty_min or ->dirty_max won't impact much, just make flush do
> some menningless operation. While counting ->dirty wrong will cause
> serious problem. If you put case 1 into purge list, freeing it later
> will fail because you can't find it in vmap_area_root tree. Please check
> vfree() and remove_vm_area().

I misread your mail. My point was soleley about the ranges which get
flushed via unmap_aliases() before the block is completely freed,
i.e. ->free = 0 and ->dirty = VMAP_BBMAP_BITS.

Thanks,

        tglx

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel