From: Artem Labazov <123321artyom@gmail.com>
To: Sungjong Seo <sj1557.seo@samsung.com>
Cc: stable@vger.kernel.org, 'Namjae Jeon' <namjae.jeon@samsung.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] exfat: Avoid allocating upcase table using kcalloc()
Date: Fri, 4 Dec 2020 15:57:33 +0300 [thread overview]
Message-ID: <20201204125730.GA546513@xps13> (raw)
In-Reply-To: <001101d6c867$ca8c5730$5fa50590$@samsung.com>
> I have not yet received a report of the same issue.
> But I agree that this problem is likely to occur even if it is low
> probability.
Perhaps I should clarify my setup a little bit more.
The issue can be reliably reproduced on my laptop. It has 8 GBs of RAM
(pretty common amount nowadays) and runs an unmodified Fedora 32 kernel.
Also, I use zswap, which seems to be contributing to fragmentation as well.
> I think it would be more appropriate to use kvcalloc and kvfree instead.
I do not think this is really needed.
Upcase table allocation is relatively large (32 pages of 4KB size) and
happens only once, when the drive is being mounted. Also, exfat driver
does not rely on the fact that the table is physically contiguous.
That said, vmalloc/vfree seems to be the best option, according to kernel's
"Memory Allocation Guide".
--
Artem
next prev parent reply other threads:[~2020-12-04 12:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20201124194858epcas1p49cacda6a9b4877ff125f25f4dc5fcadf@epcas1p4.samsung.com>
2020-11-24 19:47 ` [PATCH] exfat: Avoid allocating upcase table using kcalloc() Artem Labazov
2020-11-24 22:17 ` David Laight
2020-12-02 4:58 ` Sungjong Seo
2020-12-04 12:57 ` Artem Labazov [this message]
2020-12-07 6:23 ` Sungjong Seo
2020-12-07 9:34 ` [PATCH v3] " Artem Labazov
2020-12-08 2:22 ` Sungjong Seo
2020-12-04 13:33 ` [PATCH v2] " Artem Labazov
2020-12-07 4:32 ` Namjae Jeon
2020-11-24 18:50 [PATCH] " Artem Labazov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201204125730.GA546513@xps13 \
--to=123321artyom@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=namjae.jeon@samsung.com \
--cc=sj1557.seo@samsung.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).