[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHKZfL3YsfSLfNq268p+bikzgwvj+Ng7R09cZQk16aKio3fViw@mail.gmail.com>
Date: Mon, 29 Jul 2024 19:19:33 +0800
From: Huang Adrian <adrianhuang0701@...il.com>
To: Baoquan He <bhe@...hat.com>
Cc: Andrey Ryabinin <ryabinin.a.a@...il.com>, Alexander Potapenko <glider@...gle.com>,
Andrey Konovalov <andreyknvl@...il.com>, Dmitry Vyukov <dvyukov@...gle.com>,
Vincenzo Frascino <vincenzo.frascino@....com>, Uladzislau Rezki <urezki@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>, Christoph Hellwig <hch@...radead.org>,
kasan-dev@...glegroups.com, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Adrian Huang <ahuang12@...ovo.com>, Jiwei Sun <sunjw10@...ovo.com>
Subject: Re: [PATCH 1/1] mm/vmalloc: Combine all TLB flush operations of KASAN
shadow virtual address into one operation
On Mon, Jul 29, 2024 at 4:30 PM Baoquan He <bhe@...hat.com> wrote:
>
> On 07/27/24 at 12:52am, Adrian Huang wrote:
> ......
> > If we combine all TLB flush operations of the KASAN shadow virtual
> > address into one operation in the call path
> > 'purge_vmap_node()->kasan_release_vmalloc()', the running time of
> > drain_vmap_area_work() can be saved greatly. The idea is from the
> > flush_tlb_kernel_range() call in __purge_vmap_area_lazy(). And, the
> > soft lockup won't not be triggered.
> ~~~~~~~~~~~
> typo
Oh, my fat-finger. Thanks for pointing it out.
I saw that Andrew already added this patch to his mm branch. Let me
know if I need to send the v2 version to fix this typo. (Depend on
Andew's decision)
-- Adrian
Powered by blists - more mailing lists