[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZB01yw3MpOswyL1e@casper.infradead.org>
Date: Fri, 24 Mar 2023 05:31:55 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Dave Chinner <david@...morbit.com>
Cc: Uladzislau Rezki <urezki@...il.com>,
Lorenzo Stoakes <lstoakes@...il.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Baoquan He <bhe@...hat.com>,
David Hildenbrand <david@...hat.com>,
Liu Shixin <liushixin2@...wei.com>,
Jiri Olsa <jolsa@...nel.org>
Subject: Re: [PATCH v2 2/4] mm: vmalloc: use rwsem, mutex for vmap_area_lock
and vmap_block->lock
On Fri, Mar 24, 2023 at 04:25:39PM +1100, Dave Chinner wrote:
> Did you read the comment above this function? I mean, it's all about
> how poorly kvmalloc() works for the highly concurrent, fail-fast
> context that occurs in the journal commit fast path, and how we open
> code it with kmalloc and vmalloc to work "ok" in this path.
>
> Then if you go look at the commits related to it, you might find
> that XFS developers tend to write properly useful changelogs to
> document things like "it's better, but vmalloc will soon have lock
> contention problems if we hit it any harder"....
The problem with writing whinges like this is that mm developers don't
read XFS changelogs. I certainly had no idea this was a problem, and
I doubt anybody else who could make a start at fixing this problem had
any idea either. Why go to all this effort instead of sending an email
to linux-mm?
Powered by blists - more mailing lists