Hi,
I would like to attend the LSF/MM Summit 2019. I'm interested in topics about
BPF, mdraid, and MM. I am a designated reviewer of BPF. I am also helping Jens
organize mdraid patches.
I would like to discuss remaining work to bring THP to (non-tmpfs) file systems.
This topic has been discussed multiple times in previous LSF/MM summits [1][2].
However, there hasn't been much progress since late 2017 (the latest work I can
find is by Kirill A. Shutemov [3]).
We (Facebook) uses THP in many services. We see significant savings by putting
hot-text on THP. To achieve this with state-of-the-art Linux Kernel, we have to
either: trick the Kernel to believe certain region is anonymous pages; or put
the executable in tmpfs. In our case, the tmpfs solution is too expensive.
Therefore, we use a hack to trick the Kernel. This hack breaks other useful
features, e.g. perf symbols and uprobes. Instead of introducing more hacks to
use these broken features, it is better to enable THP for file systems.
Therefore, we would like discuss (for one more time) what is needed to bring
THP to file systems like ext4, xfs, btrfs, etc. Once we are aligned on the
direction, we are more than happy to commit time and resource to make it happen.
Since this topic is my main focus of this year's summit, I would like an invite
to the MM track.
Thanks,
Song
[1] https://lwn.net/Articles/686690/
[2] https://lwn.net/Articles/718102/
[3] https://kernel.googlesource.com/pub/scm/linux/kernel/git/kas/linux/+/hugeext4/wip
On Wed, Feb 13, 2019 at 10:00:10PM +0000, Song Liu wrote:
> I would like to discuss remaining work to bring THP to (non-tmpfs) file systems.
> This topic has been discussed multiple times in previous LSF/MM summits [1][2].
> However, there hasn't been much progress since late 2017 (the latest work I can
> find is by Kirill A. Shutemov [3]).
... this was literally just discussed.
Feel free to review
https://lore.kernel.org/lkml/[email protected]/
with particular reference to the last three paragraphs of
https://lore.kernel.org/lkml/[email protected]/
> Therefore, we would like discuss (for one more time) what is needed to bring
> THP to file systems like ext4, xfs, btrfs, etc. Once we are aligned on the
> direction, we are more than happy to commit time and resource to make it happen.
I believe the direction is clear. It needs people to do the work.
We're critically short of reviewers. I got precious little review of
the original XArray work, which made Andrew nervous and delayed its
integration. Now I'm getting little review of the followup patches
to lay the groundwork for filesystems to support larger page sizes.
I have very little patience for this situation.
> On Feb 13, 2019, at 3:59 PM, Matthew Wilcox <[email protected]> wrote:
>
> On Wed, Feb 13, 2019 at 10:00:10PM +0000, Song Liu wrote:
>> I would like to discuss remaining work to bring THP to (non-tmpfs) file systems.
>> This topic has been discussed multiple times in previous LSF/MM summits [1][2].
>> However, there hasn't been much progress since late 2017 (the latest work I can
>> find is by Kirill A. Shutemov [3]).
>
> ... this was literally just discussed.
>
> Feel free to review
> https://lore.kernel.org/lkml/[email protected]/
>
> with particular reference to the last three paragraphs of
> https://lore.kernel.org/lkml/[email protected]/
Thanks for the pointers! I will read the patches and related code.
>
>> Therefore, we would like discuss (for one more time) what is needed to bring
>> THP to file systems like ext4, xfs, btrfs, etc. Once we are aligned on the
>> direction, we are more than happy to commit time and resource to make it happen.
>
> I believe the direction is clear. It needs people to do the work.
> We're critically short of reviewers. I got precious little review of
> the original XArray work, which made Andrew nervous and delayed its
> integration. Now I'm getting little review of the followup patches
> to lay the groundwork for filesystems to support larger page sizes.
> I have very little patience for this situation.
I don't feel I am a qualified reviewer for MM patches, yet. But I will
try my best to catch up.
Thanks again,
Song
> On Feb 13, 2019, at 4:59 PM, Matthew Wilcox <[email protected]> wrote:
>
> I believe the direction is clear. It needs people to do the work.
> We're critically short of reviewers. I got precious little review of
> the original XArray work, which made Andrew nervous and delayed its
> integration. Now I'm getting little review of the followup patches
> to lay the groundwork for filesystems to support larger page sizes.
> I have very little patience for this situation.
I'll be happy to dive in and look at the changes from an mm point of view,
but I don't feel qualified to comment on all the file system
considerations.
Perhaps if someone from the fs side would volunteer; I know well how
frustrating it can be to be trapped in code review suspended animation.
On 14/02/19 01:59, Song Liu wrote:
>> I believe the direction is clear. It needs people to do the work.
>> > We're critically short of reviewers. I got precious little review of
>> > the original XArray work, which made Andrew nervous and delayed its
>> > integration. Now I'm getting little review of the followup patches
>> > to lay the groundwork for filesystems to support larger page sizes.
>> > I have very little patience for this situation.
> I don't feel I am a qualified reviewer for MM patches, yet. But I will
> try my best to catch up.
Then just dive in!
Ask questions - "what does this do?", "please explain this, I don't
understand", "I'm new here, please teach me".
Okay, some people are too busy to help much, but I've found looking
after the raid wiki that people are happy to help, *especially* if they
know that their time is going to be rewarded. If I ask for help it
usually results in an update to the wiki.
If they know you are reading through the patch asking them to explain it
helps two ways - you are another set of eyes to spot something wrong,
and your questions will make them look at their code in a new light.
Even if you don't understand what you're looking at, you can still spot
stuff that looks weird, and if you ask them to explain then it will mean
that code gets an extra check. Anything that slips through that is
probably fine.
Cheers,
Wol